Issue Description:

Swift Package manifests contain three things that may be thought of as "constraints" on package compatibility:

1. Package version number
2. Swift tools version
3. Minimum deployment targets

These are "constraints" in the sense that mismatches of these things in a dependency chain may lead to an inability to build.

Example

Consider an ecosystem with a leaf package L and a dependency D.

If package L has a dependency on D that is expressed as upToNextMinor("1.1.0"), the package manager will exclude version 1.2.0 from the space of valid resolutions for the version of D.

If package L uses Swift tools version 5.0, and dependency D uses tools version 5.0 in version 1.1.0 and 1.1.1 and tools version 5.1 only in version 1.1.2, the package manager will exclude version 1.1.2 from the space of valid resolutions for the version of D.

However, if package L expresses a minimum macOS deployment target of 10.12, and package D expresses a minimum deployment target of 10.12 in 1.1.0 and increases that to 10.13 in 1.1.1 (and on), the package manager does not exclude version 1.1.1 from the space of valid resolutions for D. Instead, it will resolve 1.1.1 (with the above constraints), and then fail the build.

Explanation

This is a very inconsistent behaviour. The observed behaviour is that the package manager appears to consider the tools target of the leaf package as an implicit constraint on the space of allowed dependency versions. Each dependency version will be checked to see whether it has a manifest suitable for the appropriate tools version, and if it isn't it will be excluded.

This can be observed with the attached Swift project: blowing away the .build directory and building with swift 5.0 checks out 1.0.2 of the dependency project. Building with Swift 5.1 checks out 1.0.3. This does not happen if you change the tools version mismatch into a minimum deployment target mismatch.

We should attempt to make this consistent. My view would be that the only signal to dependency resolution should be version number, but I suspect people may argue for the alternative.