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.
1 makes the most sense to me, but I don't know if there is a good reason for why you might want to declare `resource_type` as something other than the resource instance's type. I think that's information the instance should know about itself.

2 is also seeming reasonable.