Brings the "Running" section up to date and mentiones the new flag
"benchmark-generators"

This speeds up the build process of the main copar executable and doesn't
require as much dependencies.

As more and more benchmark suite generators are created, results published and
the tools forgotten, this creates an unnecessary burden on the everyday compile
cycle.

It was still refering to the old syntax.

Rationals were already supported, but their input syntax was the same as for
reals: Decimal fixed point notation. This is now fixed and the functor X^-
allows weights to be written as either integers or ratios of integers, separated
by a slash.

According to stackage.org, 13.11 should be the last LTS release with GHC 8.6.3,
but strangely that also uses 8.4.4. The now selected 13.10 should really depend
the older GHC.

Changes the previous hard error into a warning. We now just cap the number of
transitions at the maximum which allows for easier bisection benchmarks that
start at a low number of states.

The existing algorithm for generating unique transitions is inefficient if the
transition count is close to the maximal number of transitions. This now
switches to a different algorithm if the transition count is above 70% of the
maximum.

When the user requests more transitions than the maximal number for the given
automaton, the current generator runs into an endless loop trying to find new
unused transitions. We now detect this case early and throw an error.

It's now used to specify how many transitions you want instead of how many
transitions per state. This is strictly more powerful because you can always
just specify states*out-degree as transition count.

64bit ints were just too small to fit the number of edges in very big graphs.

The current way of iterating trough all possible edges and deciding for each
edge if we take it or not has proven not to scale to large but sparse graphs.

Instead, we now generate the edges that we want directly.

This already does all we need, so instead of duplicating the whole
implementation, just use it.

Even if it only allows a range of [1,2], it's there for completeness and makes
the benchmark script a bit easier.

This is currently only implemented for the case where --different-values is
supplied.

When the random experiment says that we should generate non-zero edge, we should
rule out the possibility that this edge gets assigned a random weight of zero.
With small --different-values, zero edges would have become way more likely.

Otherwise states get one of 2^64 different values in the initial partition,
meaning that they will be distinguished already.