Facilitate authoritative constraint ops on underlying revisions via SourceManager

[sdboyer]

I punted a couple non-MVP things in #11. One of them was authoritative revision-level fallback matching. Right now, the versionPair type allows the expression of both a branch/tag, and the corresponding underlying immutable revision. If the underlying revision is available for two otherwise-disjoint versions, and that revision is the same, then we can consider them the same.

However, there's little real guarantee at any particular point in the algorithm, or within any module of the system, that a version will have its fully paired information. That is, a Version may be an UnpairedVersion rather than a PairedVersion because it has no underlying revision (e.g., maybe if it comes from svn? or a yet-to-be-created packaging system?), or simply because the thing that created that Version instance didn't have access to the underlying revision info on hand. This is potentially problematic, as it could introduce very-difficult-to-diagnose situations where solutions differ substantially, even making the difference between SAT and UNSAT. ...Maybe. (If so, while bugs wouldn't be nondeterministic, they'd be complex enough to appear that way - aka, a mandelbug)

Now, Version objects are standalone value objects, and should very much stay that way. All solutions necessarily involve the SourceManager somehow, as that's where the information is to ensure pairing.

One approach is to add capabilities to the SourceManager for the corresponding Constraint-type methods. It can then orchestrate the procedure for each method, detecting if either of the operands are UnpairedVersions, doing the work to find their pair and then re-attempting the operation (if an underlying rev was found). The methods for this would be a little hairy, but it's the easier, sorta brute-forcey solution, as it doesn't require us to be diligent about where a Version has come from.

The maybe-better approach is to enumerate the places that Versions can come from, to the point where we can define the invariant that:

Within the scope of the core algorithm (the boundaries of solver itself), if a Version is an UnpairedVersion, there is no work that a SourceManager could do to turn it into a PairedVersion.

That'd effectively allow us to ignore the whole issue by pushing the work earlier. It'd also mean a perhaps-not-inconsiderably-less amount of work necessary for doing each Constraint op. And, being that those are a significant part of the main satisfiability problem, that wouldn't be a bad idea.

[sdboyer]

31 and #33 pretty much mean this is fixed.