Improved backend support

[NeuralCoder3]

This pull request allows for easier implementation of backends for thorin.
It builds upon the NeuralCoder3/thorin2/improved-backends branch that handles the underlying changes.
Ontop, we implement functional backends for OCaml and Haskell to showcase the backends.
Currently, some commits from higher-order codegen are merged into this branch.
Therefore, #181 should be merged first.

The CLI interface is adapted to accept the request for arbitrary backends (as opposed to hard-coded ones).
However, the LLVM backend is special-cased to allow backward compatibility with the output-ll notation.

The new notation is to invoke thorin --backend [backend-name] --output [stream].
Example:
--backend ll --output Tmp.ll
--backend hs --output -

The backend names are specified by the entries in backends as registered in register_backends.

This pull request eases the creation of new backends and helps with modularity.
Further applications would be:

• Deep embedding using the new pass infrastructure of code generators
• GPU Backends
• Separation of the LL Backend from Core
• Extraction from the Dot Backend from the inner Thorin code

Limitations

Currently, more complex programs do not work out of the box after translation.
This is not an inherent flaw of the backend but rather a carried-over issue from the printer in general.
The scoping issues (and partly also the precedence issues) carry over to the generated code.

Furthermore, not all code can be transpiled right now. For instance, dependent code segments and dialect-specific axioms are not handled in the functional backends.

The new Rust backend is more limited due to the syntactical differences between Thorin and Rust.
One problem is the concept of addressing arguments at tuple and individual levels leading to moves of non-copyable objects.

Possible improvements

The state as presented in this pull request is not optimal.
Possible improvements include:

• Easier extensions of existing backends
• Refactoring to remove code duplication and boilerplate between OCaml, Haskell, Dot, LL
• A better documentation
• More complex test cases
• Separation of the timing tests
• Refactoring to remove the boilerplate from code emitter phases

[leissa]

I think it's better to base the backends upon Emitter as in the llvm backend. Here, the Scheduler is integrated.

Currently, more complex programs do not work out of the box after translation.
This is not an inherent flaw of the backend but rather a carried-over issue from the printer in general.
The scoping issues (and partly also the precedence issues) carry over to the generated code.

That't the thing. The backends should not be based upon the Printer to begin with.