Add hls-graph abstracting over shake

[ndmitchell]

This patch creates a project hls-graph which reexposes the stuff from shake which we use. That gives us more flexibility to be explicit about what we are using from Shake, and consider moving to alternatives. Note that we use Shake in two different contexts in HLS, both as a graph underpinning HLS, and as a file-based build system. These two pieces use quite distinct subsets of Shake, so I've converted those that us Shake as an in-memory graph, but not using it as a file-based build system.

The context behind this patch is that I'm not convinced Shake is a suitable substrate as we continue to scale. Having reviewed @pepeiborra's patches adding reverse dependencies, it feels increasingly like Shake is trying to serve two masters. Concerns about garbage collection and space leaks with rdeps are problems for both Shake the build system and hls-graph the graph underpinning HLS - but in almost completely opposite ways. (That doesn't mean I don't think we should merge the rdeps into Shake, more that I'm exploring the landscape first.)

This patch doesn't require us to decide whether we use Shake or not. But makes it easier if we decide not to. Locally I have further patches that reimplement this API without Shake, but using the same approach as Shake. I'm just debugging them, and then I'll performance test, and then I imagine we'll want to have a big discussion about them. I don't think splitting the API prejudges that we'll abandon Shake though.

[pepeiborra]

Sounds great. Hopefully in a follow-up we can start extracting all of the graph-specific logic out of ghcide, e.g. the define and use functions.

hls-graph needs to be added to the list of projects in shell.nix if not done already.

[pepeiborra]

FWIW the latest version of my reverse dependencies patch is https://github.com/pepeiborra/ide/tree/keysChanged-rebased
For context, this is a patch that keeps track of what has changed since the last edit, to be used with ndmitchell/shake#802