Fix deep hash matching bug

If you were doing a ':body_exact' match with a JSON response body that
has a nested hash body, it wouldn't necessarily match the entirety of
the actual response.  Top-level keys all had to be present and match,
but nested hash keys were not required to all be present and match.

As a result of this change, several additional errors in the tests
were uncovered.

* A retrieved cookbook does not include all the metadata of a "full"
  cookbook in order to save on bandwidth

* A "minimal cookbook" includes recipes

* Attributes needed to be added to the "new_cookbook" helper method

* Attempting to delete the long description or dependencies of a
  cookbook's metadata does not actually delete these values; it resets
  them to a default.

* The cookbook read spec was using "before :all" when it should have
  used "before :each", which was causing "let" variables to become
  fixed (this is a known RSpec bug).

* The incorrect response fixtures were being used for some cookbook
  tests ('fetch_cookbook_success_exact_response' instead of
  'fetch_cookbook_collection_success_exact_respone'

* Since we are now matching nested hashes more fully, we needed to
  address the matching of lists of recipe specification hashes in
  cookbooks.  I opted to "punt" on this by having it match a Proc
  which asserts that a cookbook's "recipes" key is a list of hashes
  with the appropriate keys (not testing their values at the moment).
  It's not perfect, but it is better than what we had.
Re-implemented Hash matcher

This should be more robust, allowing both strict AND loose matching to
fully cascade down a series of nested hashes.

The logic is a little cleaner now, since we're comparing two hashes
directly, instead of on a key/value pair basis.

As a bonus, the failure messages should now be easier to interpret, as
both the actual hash and the expected "spec" hash are pretty-printed.

Tests, too!