Fix metadata nested constraints

- Fixes #103
- Fixes #182 

I wrapped this up in a [test case](https://github.com/RiotGames/berkshelf/blob/metadata_dependencies/features/install_command.feature#L241-L272) based off of #494's reproducing steps : 

```cucumber
Scenario: When a version constraint in the metadata exists, but does not satisfy
  Given a cookbook named "fake"
  And I write to "Berksfile" with:
    """
    site :opscode
    cookbook 'fake', path: './fake'
    """
  And the cookbook "fake" has the file "metadata.rb" with:
    """
    name 'fake'
    version '1.0.0'

    depends 'berkshelf-cookbook-fixture', '~> 0.2.0'
    """
  And the cookbook store has the cookbooks:
    | berkshelf-cookbook-fixture | 0.2.0 |
  And I successfully run `berks install`
  And the cookbook "fake" has the file "metadata.rb" with:
    """
    name 'fake'
    version '1.0.0'

    depends 'berkshelf-cookbook-fixture', '~> 1.0.0'
    """
  When I successfully run `berks install`
  Then the output should contain:
    """
    Installing berkshelf-cookbook-fixture (1.0.0)
    """
  And the cookbook store should have the cookbooks:
    | berkshelf-cookbook-fixture | 1.0.0 |
  And the exit status should be 0
```

This involved ditching the lockfile SHAs. After some benchmarking, I realized that it wasn't actually saving any time and just a more confusing algorithm to parse. Plus it introduced this bug that was actually fixed in the resolver long ago.

/cc @jhowarth @bluepojo @reset @ivey @justincampbell