Phase 1 of adding asset metadata saving to old Mongo

@dmitchell @cpennington Here's the first phase of my work. Look at the tests to see what is implemented and what isn't yet.
So - the storage of all asset metadata in an array in a single document springs from the planned implementation for Split. In Split, the plan is to add a few new fields to a "structures" document describing the asset metadata (the array), thumbnails, and storage type. That way, when a structure document is cloned for a different revision, the asset metadata is cloned along with it automatically. The new structure document can then update the asset metadata to change a particular asset. Splitting the asset metadata into separate documents for each asset will make this revisioning more complicated.

I agree that having separate documents for each asset would make paging easier - it'd make Mongo do the sorting work required. I was planning on sorting the arrays in the application as needed but it's unclear how costly this sorting will be.

I can keep collisions from happening by searching through the assets before adding (the code does that now), by using a top-level unique key (like AssetKey) to optimize the searching.

Anyway, the design for this asset storage defines the implementation - let's talk about this on Monday.