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.
I know, I struggled with this a bit. Specifying preferred filesystems is part of the spec, and Mark was quite adamant about Juju not being opinionated in this case. We *could* do without the options in phase 1 I think, but I don't really see a way to avoid them. Do you have some ideas?