Delete global cradle files (hie-cabal.yaml, hie-stack.yaml)

[pepeiborra]

I think this is great and I'm happy to merge it, but I have a couple of requests that can either be done in this PR of in follow-ups:

1. Inform the user that there is no cradle haskell/ghcide#788
2. Write the implicit cradle to disk
3. Give the user a choice if there are both stack and cabal project descriptors
4. Delete all the cradle files from ghcide and hls - no longer needed

Originally posted by @pepeiborra in haskell/ghcide#782 (comment)

[fendor]

If we delete them right away, won't users with older versions (HIE/HLS/ghcide) be unable to work on ghcide/hls anymore?

[pepeiborra]

If they are hacking in ghcide HEAD they should be using ghcide HEAD. But there's no rush

[jneira]

Original issue haskell/ghcide#796

[jneira]

maybe the files could be kept as an example of a complex project config?

[pepeiborra]

Can't gen-hie provide such an example?

[jneira]

Well, sort of, but the output is not exactly equal (it generates a path for each module in the exe component f.e.).
You have to install and execute the tool, of course, and you can check the file simply navigating the github repo.

[pepeiborra]

A file called hie.foo.yaml in our repository is a contract - we are telling other devs that this file can be used to load this repo in hls/ghcide. Even more than that, since we are the maintainers, we are telling them that this is the way to load this repo. And now we have made our life harder: we have to make sure to keep this file working and up to date through every change, add tests for it to make sure that it doesn't accidentally break when we upgrade hie-bios or change the layout of our repo, etc...

All that for what? I personally don't use these files anymore since gen-hie became good enough. I don't use stack either, so I am not even able to regenerate the stack hie.yaml file.

To summarise, by keeping them we are endorsing the wrong approach and making our lives harder in more than one way. So no, I don't think keeping them around is a good idea.

[ndmitchell]

Having dedicated examples is fine, even very desirable, but I think HLS should be using best practices, to encourage people to follow. I think we should now recommend not having a hie.yaml in most cases, since its easiest and works well. I've started to delete my hie.yaml files - they force a particular choice (Cabal vs Stack) which different devs make differently, and gen-hie seems to do better than my manual files in most cases.

[jneira]

Fair enough, i suppose implicit-hie is good enough to push explicit hie.yaml to special corner cases

[jneira]

So we should remove them, however, i would like to hear the opinion of the later "maintainers" of those files. We will delete the files if nobody is strongly against.
//cc @Ailrun @beberman @tittoassini @konn

[Ailrun]

So the dev flow will be use gen-hie to generate hie.yaml by dev self?

[jneira]

@Ailrun I think the idea is to use the implicit cradle and only generate the explicit config if you hit some corner case where it does not work
I assume that the implicit cradle works for hls.