Breaking resource_collection into two data containers

ResourceCollection currently fills 2 functions - it keeps an ordered list of resources to converge during the 2nd Chef phase, and it keeps a unique set of known resources keyed by the resource type and name (IE, `package[vim]`).

As part of fixing https://github.com/opscode/chef/issues/1817 I am attempting to seperate ResourceCollection into two classes that encompass the different purposes.  ResourceCollection is now a thin proxy in front of these two classes to keep backwards compatibility.

This works well for all the read-only operations accessing ResourceCollection (like `find` and `all_resources`).  But because we need to _write_ data into the ResourceCollection for 2 completely seperate purposes, I do not proxy the write operations.  Anyone writing needs to know whether they are populating the ResourceList or ResourceSet.

I haven't updated any of the tests so I expect this to rampantly fail Travis, but I wanted to get a review started with my proposed changes and see what @opscode/client-engineers thought.
Agreed on option 2. 

The only times when we are inserting things into to the ordered list is when we have dynamically created resources (our specs do that a lot for e.g.). I think it's OK to assume your defaults for these cases @tyler-ball. For the freebsd_package issue, since we will change [this](https://github.com/opscode/chef/blob/master/lib/chef/dsl/recipe.rb#L103) line to give the declaration type and the name we will be good I think.

The only case I can think of is that in dynamic resource declarations one might end up with a class name like `#<Class:0x007fc21b8bbed0>`. Probably we need to make sure we can operate the defaults with such a Class name. Probably we can cover this case with a unit test.