ma -> copar

Previously we injected each state into `a`, which had to implement
`Ord`. Now the caller has to supply `(State -> State -> Ordering)` and
handle the comparision itself. This is more efficient if the caller
knows a better way than to dynamically dispatch on the Ord interface.

Note that unfortunately there is now way around the constant boxing
and unboxing of `State` values at the boundary of the higher order
function.

Fixes #1

Bools can't be unpacked as of GHC <= 8.6, because Bool ain't a
single-constructor data type.

We don't need to know the count of edges that go outside of the block of
interest. It only matters whether there is one, so that we can correctly
return H3 in update.

The pattern

x <- read foo
modify foo (+1)

unfortunately generates one more actual read than

x <- read foo
write foo (x+1)

The property-arrays for StateRepr and BlockRepr were always stored as
a struct of arrays instead of an array of structs, but the way that
Data.Vector.Unbox works meant that you could not write to one array
without also writing to the other one. In Haskell, code like

write vec i struct { field1 = value }

would write all fields of `struct` instead of only `field1`, since the
compiler doesn't know that the fields can be stored separately. This
is now fixed by hand-implementing the struct-of-arrays data layout.

At least for the from/to values, as they are just Ints. Labels can be
anything, which means that they have to be boxed. This means that were
we previously had

Edges:  |  |  |  |
         \
          `- (Int,   , Int)
	           |
	           `- Label

We now have:

TOs:     Int | Int | Int
FROMs:   Int | Int | Int
Labels:      |     |
           \
	    `- Label

Which results in faster access to edges, especially if the label is
not required. (E.g. when enumerating predecessors of a state).

This gives a small speed boost, but most importantly can save lot's of
space and pointer indirections.

This merge commit adds an NFData instance on SomeLabel in the RELEASE
case.

This changes the command line flag from --apply-ast-transforms to
--no-functor-transforms.

While AbsorbingPolynomial has brought down the running time in many
cases, it unfortunately required quite a bit more memory than the old
Polynomial, even though the number of states and edges was reduced.
The problem here was that:

1. The overall number of labels, weights and H1 values was _not_
   reduced, they were just moved into the corresponding type of
   AbsorbingPolynomial. The only thing saved was the `Sorted` layer on
   the inner data.

2. On the flip side, the old Polynomial implementation could use very
   memory efficient unboxed vectors for nearly everything, whereas
   AbsorbingPolynomial has to store wrapped SomeFunctor values (which
   are not unboxable).

This is now solved by being very memory conscious in the
implementation of Label, H1, H3 and Weight for AbsorbingPolynomial.
E.g we use the primitive SmallArray type instead of Vector and try to
avoid indirections introduced by Maybe or Either wrappers wherever
possible.

This interprets the P(AxX) functor in MDPs slightly differently.
Instead of using labels for choices, we use unlabeled transitions and
partition the choice-states on their choice instead in the initial
partition. This corresponds more faithfully to the graph
representation of the coalgebra in our program.

For much a much better GHCi experience!

There was a typo so that it would always parse as the summand 0.

Yay, tests!

These are just the tests originally from Polynomial. Some of them are
failing right now.