Arbitrary cookbook identifiers

This proposal describes an enhancement to chef server that allows uploads of cookbooks that are identified by arbitrary IDs. This feature supports the ChefDK policyfile feature, where we intend to identify cookbooks by a SHA-1 hash of the content. This allows users to safely publish cookbook changes without updating the cookbook's version number if they choose to do so (some reasons why users might want to do this are enumerated in the proposal). In ChefDK we also intend to expose functionality that allows the user to set the identifier of a cookbook to an arbitrary string (see the proposal for some caveats about the "arbitrary-ness").

Note that nothing in this proposal prevents a user from carefully managing the versions of their cookbooks if they feel that it is valuable. Furthermore, it is recommended that this API be a bit more verbose than the current API so that users have enough information to manage cookbooks with identifiers that are lacking in semantic meaning.

Finally, pretty much the entire design is up for discussion. The design I have proposed has some outcomes that I believe are worthwhile, but there are just a few hard constraints so any design that satisfies those constraints is acceptable.
@stevendanna An example of "extended" metadata would be something like:

```
      "source_options": {
        "artifactserver": "https://supermarket.getchef.com/api/v1/cookbooks/apache2/versions/1.10.4/download",
        "version": "1.10.4"
      }
```
or

```
      "scm_info": {
        "scm": "git",
        "remote": "git@github.com:opscode-cookbooks/homebrew.git",
        "revision": "5dd60680eac8de6c85a4de917db6956b8160c931",
        "working_tree_clean": true,
        "published": true,
        "synchronized_remote_branches": [
          "origin/HEAD -> origin/master",
          "origin/master"
        ]
      },
```

But maybe that's getting a bit verbose? Should we boil it down to "upstream_url" and "upstream_id" or something like that? I was intentionally vague about this at first.