Migrate from crane2nix to crane; make Haskell repl/ghcid work

[srid]

https://ipetkov.dev/blog/introducing-crane/

In addition to simplifying the Nix code quite a bit, this prepares the ground for switching over to the dream2nix-based https://github.com/yusdacra/nix-cargo-integration (which uses crane as the default backend).

But why don't we do that right now? Because nix-cargo-integrations exposes a monolithic makeOutputs that gives us a Rust flake, but what we need really is the more fine-grained attributes of the crate derivation and dev shell - to make it work with our multiple-language flake. Ability to compose multiple Flakes doesn't exist and seems to necessitate hacky code (see NixOS/nix#4218), so I decided against doing this today. Perhaps we should consult with @yusdacra.

Incidentally, this PR also

• fixes troubles with cabal repl (and thus ghcid) not being able to find the Rust library (as @mlitchard experienced so far). It fixes it by using LD_LIBRARY_PATH after telling in Cargo.yml to build the dynamic library alongside the static library.
• obviates needing a compiler hash suffix in library name. FWIW, we are no longer using the Rust overlay, and instead use the compiler from nixpkgs.

[MatthewCroughan]

If you think it necessitates hacky code, read and understand NixOS/nixpkgs#167947. Most of the time, when you think you want a subflake, you do not.

[srid]

You still have to write a compose function for lockless subflakes.

[MatthewCroughan]

@srid I do not yet fully understand why you need to do this composition of subflakes. I am not understanding a lot of the changes, which is why it is likely that you will be maintaining this repo, and I will not be able to contribute to it.

[srid]

Closing in favour of #13

I appreciate your input here @MatthewCroughan for having me re-evaluate this approach.