Bring back general-purpose noms migration

[aboodman]

cc @willhite, @cmasone-attic

[aboodman]

Note that I pushed a v7.12 branch to the noms repo to make this work, and renamed all the imports in that branch: 4d4f023

I'm not sure whether vendoring the v7 dependency is worth it or not. The gopkg.in dependency will redirect automatically to the biggest v7.x branch on github. Maybe that's sufficient to avoid duplicating all this storage in our repo?

[aboodman]

Answering myself ... I think the branch is sufficient. No need to clutter up the repo. I'll take out the vendored noms before landing this.

[aboodman]

Also after thinking on it, I feel like the package names should be fine-grained with the subversion. So in this case, the package names in the branch should be 7.12. That way we can support migrating across minor versions if desired.

[ghost]

Sorry. Forgot this was waiting on me. Is it ok if I review on Monday?

[aboodman]

It's not high priority. @willhite and I were talking about it in meatspace.

[ghost]

In general, I'm still ok with this approach. I'd put money on their already being other subtle issues here that I'm not thinking of, but I buy the argument that we need this and now that we have data that we want to migrate, it's worth getting experience with how well this works.

It's kind of a bummer that the binary size of noms is going to nearly double here, but we can always split it out later if we want.