Migration plans in database

[stuartpb]

Now, I don't want to make the migration plan tooling too robust, since the current design is really to just copy-paste it in from a Gist that does proper version control and all. However, #14 (by way of #13) has forced this to get a little more robust than the current localStorage out-of-band hack, so there'll need to be a document for this in the DB.

Some thoughts:

• It'll probably have an _id like reslackPlan (the current name of the plan in localStorage, even though that's gross). I thought about having it have a random UUID and making it findable by type, but really, all that does is make it possible to end up with conflicting plan documents floating around in one database, which would be bad. This way, Pouch would at least be able to tell that there's a mismatch if two conflicting plans were somehow uploaded.

I'm thinking it should contain:

• The YAML source for the plan
• The source of the last working YAML, if the current source does not compile

I was thinking about having it also serialize the parsed version, but now that I think about it, not only is that redundant, it also makes the plan document's deep structure potentially non-uniform, so, nah. The "last known working YAML" idea, though, seems like it might not be a bad idea (though, eh, it might be).

[stuartpb]

Oh, looks like I've already got the machinery to do this in place, calling it "dreamplan".