if there is no Global or User Global PLT file create a project local one

This removes the requirement that the user have a plt file in thier
home directory. This change will set the makefile use that PLT file if
its there, but otherwise it will create one local to the project. It
does this transperantly to the user. It also removes the old number 2
option from the README.md. A PLT file is actually not optional, since
its required for the 'make' command to finish. This change should
provide enough information for that to be redundant anyway.
fix a bug in the rebar warning

Previously if rebar was not there the makefile would blow up (the
indentation in the conditional was the problem). This fixes that.
add the PHONY to the makefile for the non-file rules

Rules in make are all geared towards files. It does a lot of stuff to
check and see if files have been updated and need to be rebuilt. When
you have rules that are not files it can result in some wierd
behaviour (as make rebuilds things that should not be rebuilt). You
get around that by telling make what rules are not files with the
'PHONY' variable. You may or may not hit this problem, but having
'PHONY' is just good makefile engineering and avoids those problems
entirely.
version bump 0.0.2

There has been a lot of change since the last release. So this bumps
the version to keep to semver.
Make the types a bit cleaner with the addition of constraint_op()
support full semver style version strings

This supports full [semver](http://semver.org) style version strings and correct
Version bump 0.1.0 (due to api change)
Fix invalid constraint test to conform to new API

The semver addition means that additional data is returned from
version parsing.
Whitespace
Use the proper auth_group_design name
Upgrade to latest neotoma and use it as a dev-only dep

The latest version of neotoma fixes the escript build issue we had
seen in the past that had an error trace like the following:

  ```
  ==> neotoma (escriptize)
  'src/lucene_txfm.erl' already exists, skipping generation.
  escript: exception error: no match of right hand side value
  {error,enotdir}
    in function  neotoma:file/2 (src/neotoma.erl, line 42)
    in call from escript:run/2 (escript.erl, line 741)
    in call from escript:start/1 (escript.erl, line 277)
    in call from init:start_it/1
    in call from init:start_em/1
  make: *** [lucene] Error 127
  ```

The generated parsers are not updated with this commit, but verified
that they now build and the changes are minimal based on a few feature
additions to neotoma.

The Make infrastructure has been updated and re-organized and
dependencies ej and jiffy updated to latest tags used elsewhere in
erchef stack.
Merge branch 'sf/eric-semver'
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'