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.
To be clear, nothing about this proposal as it is now would fix this for the existing `/cookbooks` endpoint; that's much more involved, since the dependency solver needs to be upgraded to deal with extended versions, the database schema would have to change (implying a data migration) and we need to do a *lot* of testing to make sure changes to that code base don't change API responses to existing data (for a recent change, we had to write a service to run the old and new code against every user query in Hosted Enterprise Chef). So I've left that out of this proposal. But long term, if the existing endpoint just becomes a "private supermarket" and we remove the server-side dependency solver, then a lot of that difficulty goes away.