Autoloader: A potential issue with different major versions of dependencies

I looked into the Jetpack autoloader when doing some reviews. It seems like an interesting approach to the problem of trying to drop plugins, each with their own vendor directory full of dependencies, into an existing installation without requiring a top level `composer install` to properly collect all the dependencies into one vendor directory.

For example, if a plugin uses "some/library" at version 1.0.3, and another plugin uses "some/library" at version 1.0.7, our autoloader will pick the 1.0.7 version.

But consider if a third plugin brings in "some/library" at version 2.0.0, which (as indicated by the semver version number) has breaking changes with respect to the 1.x series. Our autoloader would pick 2.0.0, which might break one of the first two plugins if they use something from the library that was removed or changed.

Remember that even if we avoid this in our own libraries by releasing a "some/libraryV2" instead of a 2.0.0 version, the autoloader may also be used to bring in other libraries that likely don't do that sort of thing.

Composer itself handles this sort of situation by raising an error when you try to `composer install` or `composer update`, complaining that no version satisfies all the dependencies. The third plugin might even avoid the problem by depending on "~1.0.7 || ~2.0.0" (and doing library feature detection somehow in-code).

At the least, we might log a warning of some sort if we have to choose between different major versions. Ideally we might collect the constraints applying to each package in addition to the package's version in the generated `jetpack_autoload_*.php`, and use that when autoloading to select the best version of the package (or raise an error if no version satisfies all constraints) instead of just picking the highest.

Start with the Jetpack autoloader and the generated jetpack_autoload_*.php files, then trace how package versions are selected. Compare that behavior with the described Composer conflict case and determine the expected handling of incompatible major-version constraints; the issue leaves the warning, selection, or error design open.

Written by the indexing model from the issue text.