Separately enumerate/split out some of the inputs to the lock's memo

[sdboyer]

The memo field in the lock is an important component in the overall strategy for making dep fast and reliable. Its exact behavior is described in greater detail in the gps wiki, but the essence is this: it's a hash digest of string representations of all the locally-knowable inputs that could affect solving outputs. When dep ensure or dep status (or whatever) are run, they pull together all this locally-available info, compute a hash, and compare it to what's in Gopkg.lock. If it's a match, then we know the project's code+Gopkg.toml are in sync with Gopkg.lock. (This is literally memoization, which is why the field is named what it is).

However, as with all hash-matching schemes, it has the disadvantage that, if there's ever a mismatch, we cannot know why that mismatch occurred. And, if hash inputs can vary in ways that are non-obvious to users (like, say, the totally-not-visible-outside-the-code analyzer version that is incorporated into the memo), team members can find themselves ping-ponging hash changes back and forth with each other, and/or a CI server, with no idea what the problem is. That would rapidly turn such mismatches into a false alarm, causing people to ignore it. That would certainly undermine the overall UX of the system that we're going for, and possibly even a real aspect of system integrity.

Now, I do think the hashes have value. We could, for example, create a simple HTTP service that takes a hash and returns a solution for it, thereby obviating the need for solving. Or, more low-tech, just keep a history of solutions somewhere else on disk locally, memo-addressable, the hash provides a convenient addressing system in this respect. But we need to split out some of the information in the memo into separate, explicit fields in Gopkg.lock so that we can provide more detailed feedback users about what might be causing weird mismatches.

I don't have a specific plan on this yet, but I'll update the ticket when I do.

[sdboyer]

Hmm, this should probably incorporate #421.