This was long obsoleted by the polynomial functor

Currently this just contains one very simple benchmark for the
morphism parser, but more will come in time.

These are now subsumed by the polynomial functor

This begins the implementation of the polynomial functor. It currently
only implements the morphism parser and neither the refinement
interface nor the functor expression parser. Both will come at a later
state.

This is only temporal and demonstrates the fact that multi-argument
functors are implementable. In the future this will be replaced by a
more general polynomial functor, but the parsing infrastructure for
functor expressions can't handle that yet.

This allows files to exists in the examples directory that don't have
a ".out" file. These are now ignored in the test suite. Such files
could be documentation or ephemeral tests.

All files in examples/ now have a corresponding .out-file that is
checked against the algorithm's output on that example as part of the
test-suite.

Instead of one big Algorithm.hs, there are now separate modules for
`initialize`, `split` and the queue handling stuff. This hopefully
makes the code structure a little more clear and also allows us to
export utility functions (like `initialize` and `split`) from
submodules for testing, while still keeping a tidy export list in the
toplevel module.

Still not used by the algorithm, but at a step in the right
direction...

The RefinementInterface class contained several type families (or
associated types) like Weight or H1. It turns out that we also need
these definitions in other classes and to avoid unnecessary
dependencies between those type classes and RefinementInterface, the
type families now have their own home in RefinementTypes.hs.

This is still not final and has several API problems. E.g implementing
ParseMorphism for SomeFunctor is currently not possible without a
warning about unimplemented methods.

Implements a new morphism parser that doesn't depend on yaml and has
much nicer properties in "MA.Coalgebra.Parser".

This is not yet complete:

  - Needs more testing
  - Needs to handle special cases better
  - Needs a way for SomeFunctor to retrieve it's own sort

I use this almost everywhere I used monads

This is an existential that can wrap any functor that implements the
refinement interface. It will be used to do proper desorting in the
future, but right now it's a big hack to support the old
infrastructure while slowly migrating to new-style functors.

doctest doesn't respect the `default-extensions` field from the cabal
file, so we previously had to put every extension at the start of each
and every file so that doctests would compile.

Using the `cabal-doctest` package, we can pass the right options to
`doctest` at build time and move extension declarations to the cabal
file.

Unfortunately, moving the GHC-extension declaration to the cabal file
broke our doctests...