Capture implicit constraints explicitly

**Motivation.** When specifying version bounds for software published to Hackage, there is a tension between specifying a conservative upper bound `< 1.7` (because `1.7` has not been released yet, and COULD break your package) and not specifying an upper bound (because it's possible your software MIGHT work with 1.7). In an ideal world, we would have two separate types of bounds:
1. Explicit bounds, which are known at the time a package is authored and uploaded. For example, if I say `p >= 0.2`, it's because I definitely know that `p-0.1` doesn't build with my package
2. Implicit bounds, which are unknown at the time a package is authored and uploaded. Continuing the previous example, if p-0.3 is not released at the time I upload my package, I do not know if I should apply the bound `p < 0.3` to my package. If I am being conservative, I should, because p-0.3 could be BC-breaking in a way I care about; but p-0.3 could work fine, in which case my upper bound might actually be `p < 0.4` or `p < 2.0` (who knows!)

The present requested behavior from package uploaders is to upload a package with a restrictive upper bound, and then relax it (using the Cabal file editing interface on Hackage). But this is a lot of work for maintainers, and this work doesn't even benefit Stackage users, who aren't using the dependency solver at all. In fact, the speculative bound is a pain because it will cause Setup configure to reject a dependency, even when it might have worked.

**Approach.** Implicit bounds required by the PVP should be tracked and recorded by Hackage, rather than being written to Cabal files. Package authors no longer have to write speculative upper bounds; Hackage will automatically pick an appropriate upper bound, and there will be a channel for successively relaxing it.

**Goals.** Here's what we want to achieve:
- The application of implicit bounds to a package should be backwards-compatible, in the sense that all existing cabal-install clients should get these new constraints. (This imposes some major restrictions on how we implement this.)
- The implicit constraints are able to be adjusted easily, possibly, automatically. For example, if a Stackage nightly shows that a given implicit version bound can be moved up a notch, then this can happen via a webhook or other technical measure.

**Details.** This issue proposes to explicitly capture the implicit constraints, outside of the cabal file.

The simplest way to do this, keeping existing functionality intact but allowing the implicit constraints to move out of the cabal file, would be capture them on hackage, by modifying the meta-data editing capability. This would allow either the package uploaders or hackage trustees to modify the implicit bounds, which are stored outside the cabal file, and the implicit ones, which are now stored in a new file, associated with the package/version.

It would make sense for the initial implicit constraints to be optionally set by the uploader, perhaps using something like [cabal-bounds](http://hackage.haskell.org/package/cabal-bounds). Alternatively they can be captured in a new file, parallel to the existing one. As they are implicit, this should not be necessary.

The hackage web interface will show both constraints on the dependencies, but highlighting in some way to differentiate them.

When the `00-index.tar.gz` file is constructed for download, it should contain the original cabal file for each package, as well as a new file containing the current values for the explicit constraints.

Under normal usage, cabal install will combine the constraints in the cabal file with the new implicit ones (perhaps using the `config.cabal` mechanism), and configure as per normal.

When another installer such as stack operates, it can choose to not use the implicit constraints if it is using its own constraints, or to use them when it needs to invoke the cabal/hackage resolver.

**Other notes.** There is also a proposal for [package sets](https://mail.haskell.org/pipermail/cabal-devel/2015-July/010214.html). They appear to be orthogonal to this proposal.