Auxiliary resolver specification files (stack.<resolver>.yaml)

[harendra-kumar]

Currently stack.yaml allows only one resolver specification and one extra-deps section. When we want to use a multiple resolvers we have to create multiple stack.yaml for each case. This creates a redundancy because we usually want to keep rest of the settings in stack.yaml common to all cases. Also these files are to be explicitly specified on the command line. Since there is no naming convention, stack will not be able to use them automatically based on your global configuration.

I propose that we allow an additional config filestack.<resolver>.yaml per resolver to keep extra-deps for a given resolver. If present this file will be read and the extra-deps specified in it will be used with the given resolver when selected.

An alternative implementation would be to use multiple resolver or extra-deps section in the main stack.yaml. But I would rather prefer a separate per resolver file.

Think about the following use cases:

1. I want to use a system compiler since it is already installed. I do not want to download and install another GHC and waste space.
2. I want to use the same compiler for all my builds because I do not want to install multiple GHC versions and waste a large amount of precious space.
3. I want to test a project with multiple compilers where only compiler/snapshot changes but the rest of the config remains the same.

With this feature, project maintainers can provide multiple resolvers, one for each compiler version. stack init or stack solver can also init the project for multiple resolvers. If your preferred resolver is not in the stock stack.yaml you can init it without touching the main config file. When multiple resolvers are provided by the project maintainer stack can automatically choose the one matching your compiler. Or it can use solver to automatically init for your compiler or your preferred resolver. Since the main file does not have to be changed we do not need to ask the user to explicitly specify --update-config and therefore it can work automatically based on user config.

When used with #1590 it will make it super convenient to use your preferred compiler with any stack project.

Related #2546.

CC @mgsloan @borsboom @sjakobi @Blaisorblade

[borsboom]

This would also go along with a more general way to have mutliple stack.yamls with overrides, like say a stack.local.yaml in which a user can put local settings that shouldn't be committed to source control in the main stack.yaml (it's been discussed before, not sure if there's already an issue).

[borsboom]

Ah, here's the issue I was thinking of: #732