Charm storage metadata

We introduce a new "storage" attribute to charm metadata, which describes required and optional storage for a charm. Each may be raw block devices, or file systems. The charm declares the name, type and some restrictions on the storage, and the administrator specifies how to fulfil that storage when deploying the charm.

The metadata format is based on the storage phase 1 scope document:
https://docs.google.com/a/canonical.com/document/d/1-9ZPfdgpkj2R9mBG_tlSclGGyK3tRpMf2L4C37mzYD8/edit#bookmark=id.6abw2ee0ebgm

which is mostly the same as described in the spec: https://docs.google.com/a/canonical.com/document/d/1OhaLiHMoGNFEmDJTiNGMluIlkFtzcYjezC8Yq4nAX3Q/edit

Note that the spec was never signed off, and the scope document is yet to be reviewed. This metadata format is subject to change, and should not be documented until it is finalised. In the short term, this unblocks further work on storage in Juju (which should be uncontroversial).

There are also two new hook kinds defined for notifying units of storage attachment and detachment.
> hmm, not sure we want bson serialization here, do we? Yaml, yes, because that's the native format for charms -- but we don't want our DB "schema" defined outside state, lest we change it accidentally.

I took my cue from the existing Meta structure. state/charm.go already directly uses charm.Meta as a document struct field. This can be changed of course.