force_latest_compatible_version: explicitly ask the resolver to look for a solution

[DilumAluthge]

Summary

This PR is a follow-up to #2439.

Specifically, this PR implements @00vareladavid's suggestion in #2439 (comment):

Something that could be done (possibly in a future PR) is to take the set of version ranges you compute and add them during the sandbox resolve step. That way you can error out with a resolver trace of why it was not possible (in the case that the resolve step fails). It seems it would give you a better shot of meeting those requirements since you would be explicitly asking the resolver to look for a solution.

Before this PR:

1. Pkg.test sets up the temporary sandbox project.
2. Pkg.test runs the resolver inside the temporary sandbox project.
3. If force_latest_compatible_version is false, we do nothing. If force_latest_compatible_version is true, we assemble the list of all direct dependencies, and then loop over the list; for each direct dependency DepName, we take the following steps:
   1. Inside the temporary sandbox project, we check and see which version of DepName the resolver selected.
   2. We assemble the list of all registered versions of DepName.
   3. We iterate over each version from step (ii), and for each version, we determine whether or not that version is inside the [compat] entry for DepName. At the end of this step, we have a list of all registered versions of DepName that are compatible with the [compat] entry for DepName.
   4. We take the maximum of the list from step (iii). This gives us the latest registered version of DepName that is compatible with the [compat] entry for DepName.
   5. We compute the earliest version number V such that all changes from V to the result of step (iv) are backwards-compatible.
   6. If the answer from step (i) is strictly less than the answer from step (v), we throw an error. Else, we do nothing.
4. Pkg.test runs the tests/runtests.jl file.

The algorithm for computing step (v) above is as follows. The input is a version number of the form x.y.z.

• If x > 0, return x.0.0. (This is because, for x > 0, all changes from x.0.0 to x.y.z are backwards-compatible.)
• Else, if y > 0, return 0.y.0. (This is because, for y > 0, all changes from 0.y.0 to 0.y.z are backwards-compatible.)
• Else, return 0.0.z.

After this PR:

1. Pkg.test sets up the temporary sandbox project.
2. If force_latest_compatible_version is false, we do nothing. If force_latest_compatible_version is true, we assemble the list of all direct dependencies, and then loop over the list. For each direct dependency DepName, we check if the project has a [compat] entry for DepName. If the project does not have a [compat] entry for DepName, we do nothing. If the project has a [compat] entry for DepName, we take the following steps:
   1. We get the original [compat] entry for DepName.
   2. We assemble the list of all registered versions of DepName.
   3. We iterate over each version from step (ii), and for each version, we determine whether or not that version is inside the original [compat] entry for DepName. At the end of this step, we have a list of all registered versions of DepName that are compatible with the original [compat] entry for DepName.
   4. We take the maximum of the list from step (iii). This gives us the latest registered version of DepName that is compatible with the original [compat] entry for DepName.
   5. We compute the earliest version number V such that all changes from V to the result of step (iv) are backwards-compatible. The result of this step is a version number V of the form major.minor.patch.
   6. We delete the original [compat] entry for DepName and set the new [compat] entry for DepName to "^major.minor.patch", where the numbers major, minor, and patch are taken from the result of step (v).
3. Pkg.test runs the resolver inside the temporary sandbox project. Note that this will use the new [compat] entries that we generated.
4. Pkg.test runs the tests/runtests.jl file.

The algorithm for computing step (v) above is as follows. The input is a version number of the form x.y.z.

• If x > 0, return x.0.0. (This is because, for x > 0, all changes from x.0.0 to x.y.z are backwards-compatible.)
• Else, if y > 0, return 0.y.0. (This is because, for y > 0, all changes from 0.y.0 to 0.y.z are backwards-compatible.)
• Else, return 0.0.z.

[DilumAluthge]

I want to land #2469 (comment) or something similar before we move forward with this PR. It will simplify the implementation.