Bimodal analysis

[sdboyer]

For #35

Impl plan

• Attach methods to source managers for analysis
• Reconfigure adapter to make it injectable-ish for tests
• Pull in stdlib package list from tip. (so, just ignore core go version for now)
• Add funcs to suss out the repo from a package name
• Add logic for adding, w/open constraint, things in analysis that aren't in manifest
• Skip special rules for now, just ignore things in manifest but not analysis
• Change selection structures to operate on both projects and packages
• Implement new testing harness specifically for exercising bimodal analysis
• Create new selection path for when we're just adding packages to an already-selected project
• Testing fixtures for all the reasonable basic permutations of inputs, exercising {0,1,N} behaviors, transitivity, backtracking, multi-stage dep integration, etc.
• Modify unselected comparator to always have package-only additions float to the top - those are always more incremental changes
• Revisit how fail() analysis chooses what to mark
• Circle back on whether we need to look at all imports, or just the current atom's, in solver.getImportsAndConstraintsOf()
• Add satisfiability check that, if a project/version is already selected, all pkgs targeted within it exist. Also add the reverse, that if a project is being checked and deps already exist, it has the packages already depped upon
• Incorporate stdlib list in lock input hashing (they amount to ignores, and COULD change)
• Refactor HashInputs() to incorporate root project static analysis
• Get static analysis actually working as expected

[sdboyer]

Finally got things together to the point where I'm integrating the analysis bits into the core of the algorithm. There are a couple classes of things to handle. First is moving from package names to repos - which, for now, we take to be the same as projects.

• We have to exclude stdlib packages, or other things that don't have, or appear to have, a network-addressable identity
• We have to translate the package names (those not excluded by the preceding) back down to their repo roots, if we can. Obnoxiously, this may entail a remote HTTP op

Second, we have the issues described originally - discrepancies between the manifest and the analysis.

• We could have some things found in the reach that aren't in the manifest. This is easy - we take them, with an open constraint.
• We could have some things in the manifest that aren't in the reach, in which case we have two choices:
  • Ignore some or all of the extras
  • Incorporate some or all of the extras with special rules - select all of their non-main packages

[sdboyer]

bleh bleh turns out the static analysis needs work, and tests. doing that, then i think i can finally merge.

[sdboyer]

WE HAVE FINALLY ARRIVED 🎉🎉🎉🎉🎉🎉🎉