RFC: Nix backend

## Motivation

The current Nix-style store implementation works well but has a number of limitations, such as

* No garbage collection (#3333)
* Sharing/deploying build products can be difficult (#462, #5582, ...)
* Only the version (not the specific instance) of system dependencies is considered in the hash (ironically, this can be a problem when using cabal-install in NixOS)
* Path length problems (too many to list)

Nix can solve many of those problems, but Nix as is requires total buy-in to be useful, which means using the Nix expression language and command line, and a cabal user may not be interested in those.

cabal-install 3 is uniquely positioned to transparently take advantage of the store part of Nix without having to sacrifice its own solver, cli, or ability to perform incremental builds on local packages.

## Proposal

I propose to:

* Modify cabal-install so that it can build remote (=saved in the store) packages through multiple backends
* Add a Nix backend that produces Nix derivations directly (without passing through the Nix language) and delegates the build to Nix

If [Nix RFC 134](https://github.com/nixos/rfcs/blob/master/rfcs/0134-nix-store-layer.md) is implemented, this will be based on a stable interface independent from Nix-the-language.

## Challenges

The main challenge is designing the interface of cabal-install backends. While the similarity of Nix and the Nix-style store helps, there are a few obstacles to consider, for example:

* The current implementation expects the store to have a single mutable package db.
* The current implementation can interleave remote and local builds, Nix will only do remote (non-incremental) builds.

The interface has to be flexible enough to accommodate for these differences.

## Future work

If this turns out to work well _and_ [Nix RFC92](https://github.com/NixOS/rfcs/blob/master/rfcs/0092-plan-dynamism.md) is implemented, cabal-install can be used to generate build plans directly in nixpkgs without recursive Nix, closing the loop and demonstrating how system package managers and language-specific package managers can integrate even when dependency trees become complex.

## Prior work

#3882
[haskell.nix](https://input-output-hk.github.io/haskell.nix)