Accept AbstractResolvers as valid resolvers in stack.yaml

This is an improvement request.

It would be great if you could specify an abstract resolver as a resolver in a `stack.yaml`.
To clarify the term, on the command line, you can specify a certain resolver to be used with the `--resolver` flag. This flag does not only support specific resolver specifications (like `lts-6.10` or `nightly-2016-08-06`, represented internally by `Resolver`), but also abstract specifications like `lts` or `lts-6` (represented internally by `AbstractResolver`).
This abstract resolver is later turned into a concrete one with `makeConcreteResolver` (in [`src/Stack/Config.hs`](https://github.com/commercialhaskell/stack/blob/4a560330bd447852171ad5e18d668732977d869c/src/Stack/Config.hs#L157-L186)). However, you can't currently set such an abstract resolver in a ´stack.yaml` file.

The [user guide provides two reasons](https://docs.haskellstack.org/en/latest/GUIDE/#resolvers-and-changing-your-compiler-version) why this currently isn't possible:
1. [It will] slow down your build (since stack then needs to download information on the latest available LTS each time it builds)
2. [It produces] unreliable results (since a build run today may proceed differently tomorrow because of changes outside of your control)

First of all, I think both points are very valid, however there surely are tons of other ways to shoot yourself in the foot using stack (or cabal, etc.). A warning when trying to specify an abstract resolver the first time might hinder the unknowing newcomer from getting himself in greater trouble.

To address point 1 in particular, I think a simple timestamp saved somewhere in `.stack-work` could largely resolve the issue.

Regarding point 2, I'd say that `stack.yaml` is first and foremost a development file. While cabal considers the cabal files of dependencies, stack.yaml files are really only read when building the very project they are located in. This limits the point of somewhat unexpected behaviour to one file that is most likely located in your working directory. Furthermore, stack could provide a warning that it is switching the resolver. Similar to cabal's freeze command that freezes dependencies in a sandbox, stack could provide a freeze command that changes an abstract resolver into a concrete one and an unfreeze command to do the opposite.

On the other side, I'd say there are considerable merits in making this change: Concrete nightly resolvers are more or less out of date 24 hours after their release (with exceptions, of course), `stack-8.0.yaml` in this very project points to `nightly-2016-07-19`. There is nothing special about that nightly version, and even if it had been set to a specific version because later nightlies caused problems, that would be an undesirable workaround: After all, stack (or all other projects, for that matter) should work and be tested with newer versions of its dependencies. Similarly, users of `lts-6.0` should really upgrade to the latest `lts-6`, after all, the motivation for LTS Haskell was smooth intra-major updates.

I'm very much looking forward to your comments!