ghcup provision (or ghcup setup-env) etc.

[hasufell]

To discuss: instead of running ghcup install ghc 9.2.8 && ghcup install ghc 9.4.8 && ... one could imagine a way to declaratively specify the whole toolchain setting and let ghcup execute that description as a whole, e.g.

GHC: [9.2.8, 9.4.8*, 9.6.3]
Stack: [latest*]
Cabal: [latest*]
HLS: [recommended*]

or some-such. There's some design-space to explore (e.g. where to read the data/file from), whether to support some form of .ghcup file in PWD, etc.

[runeksvendsen]

As discussed privately with @hasufell: note that whatever DSL the above example is parsed into would also be useful for #64. In the integration test, we could imagine a test case that installs the above tools/versions and asserts something about the resulting environment, and in that context it would be useful to have a DSL for expressing a set of tools to install/set.

[runeksvendsen]

One could also imagine a new command ghcup shell which drops the user into a shell in which the tools specified by .ghcup are available (ie. instead of installing them globally).