Refactoring duplicate code between storage.key and storage.bucket.

@tseaver We discussed this waaaay back in #238.

Let me know how much of the tests you want me to move from `Bucket` / `Key` specific stuff into `test__helpers`.
FWIW:  right now, the "metadata" we fetch is the full `Bucket` representation, including keys (from #314):

- `cors`
- `etag`
- `id`
- `lifecycle`
- `location
- `logging`
- `metadata``
- `metageneration`
- `name`
- `owner`
- `projectNumber`
- `selfLink`
- `storageClass`
- `timeCreated`
- `versioning`

Of those, the mapping stored `metadata` key is the only one not managed by gcloud:  it contains appliation-specific key-value pairs.  #313 outlines the similar set of fields for the `Object` representation we fetch for keys.

I'd like us not to conflate the application-specific `metadata` key with the broader set of keys in the `Bucket`/`Object` representations:  in fact, I'd like us to have accessors for each of them, and use `get_metadata()` / `patch_metadata()` only for the application-specific mapping.

We can go ahead and merge this PR without waiting for those issues to land.