Update and compat fixes for new depsolver with semver support

* Update tests for new API of depsolver with semver support
* Remove local ec_plists copy, make erlware_commons a proper
  dependency again.

Chef does not yet support semver for cookbook versions. This patch
wraps depsolver's new API for solve.
Fixed data bag item indexing

Data bag indexing was not implemented correctly. The Ruby server sends
the data bag with the original data. Erchef had been nesting the data
bag data under the key, "raw_data". This causes knife search to fail.

Specifically, the Ruby code calls #to_hash, not #to_json, and the Erlang
code had implemented #to_json.

For reference:

https://github.com/opscode/chef/blob/10-stable/chef/lib/chef/data_bag_item.rb#L137-L143
Merge branch 'hh/CHEF-3975/fix-search-indexing'
Added eunit tests for chef_objects:ejson_for_indexing (data_bag_item)
Change the environment cookbook_versions validator to use the constraint_map_spec api used by cookbooks.

* environment cookbook version validator now uses the same
  constraint_map_spec as used by cookbooks.
* remove 'null' as a valid option for cookbook_versions as an experiment.
* use more strict cookbook version validation: empty and single-element lists will be rejected
* accepting version strings without qualifier, treating  "1.0.0" as "= 1.0.0"
Merge pull request #39 from opscode/ma/oc-6988

Squashed and merged.
Remove "providing" field validation from  cookbook metadata

As per discussion in http://tickets.oscode.com/browse/CHEF-3976

We should be able to use the 'provides' examples from our published docs
(http://docs.opscode.com/config_rb_metadata.html) but the server will
reject these as invalid cookbook metadata.

The "provides" field in the cookbook metadata were not intended to be
machine readable. It is not used for anything on the server. However,
knife will reinforce some constraints. Using the example from the docs:

    maintainer       "Chef's"
    maintainer_email "chef@opscode.com"
    license          "All rights reserved"
    description      "Installs/Configures joy_of_cooking"
    long_description IO.read(File.join(File.dirname(__FILE__), 'README.md'))
    version          "0.0.1"

    provides "cats::sleep"
    provides "cats::eat"
    provides "here(:kitty, :time_to_eat)"
    provides "service[snuggle]"

Knife will send up a JSON that has this for metadata.providing:

    {
      ...
        "providing": {
          "joy_of_cooking": ">= 0.0.0",
          "cats::sleep": ">= 0.0.0",
          "cats::eat": ">= 0.0.0",
          "here(:kitty, :time_to_eat)": ">= 0.0.0",
          "service[snuggle]": ">= 0.0.0"
        }
    }

It was decided to remove the validation completely. Eunit tests have
been updated to reflect this new reality.
Merge branch 'hh/CHEF-3976/provides_validator_in_metadata'
Add oc_chef_authz_db:fetch_group_authz_id/3

We only need the ID now, so this is a simpler solution that doesn't
require creating a "chef_group" record.
Add oc_chef_authz:add_client_to_clients_group/3
Add oc_chef_authz:remove_actor_from_actor_acl/2
Formatting
Type-awareness for entity creation / manipulation

We need to create actors now, too; not just objects
Allow superusers to bypass container perm check
Initial pass at oc_chef_wm_base:maybe_process_client/2
Spoof validator client id with superuser

Also extract creation logic into do_create_in_container/4
Block creation of validators by validators
Remove validators from their own ACLs

This is consistent with current OHC behavior, as well as with our
desire that validators should only ever be able to create new clients.
Add chef_wm_base:maybe_process_client/2

Open Source Chef Server and Private Chef Server process clients a
little bit differently.  This seems like the least invasive way to
handle it, and it fits with the pattern we've taken with similar
issues in the past.
Clients are actors