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.
@mcquin The original problem is that the cookbook is written as `package[vim]` but the resource is inserted into the ResourceCollection as `freebsd_package[vim]` on BSD.  # 1 would solve that issue by allowing the Resource::FreebsdPackage instance to know it was declared as `package[vim]`.  Then it could tell the ResourceCollection to reference itself as `package[vim]` so `notifies :install, 'package[vim]'` would work correctly.

But it seems like option # 1 is :-1: because it either involves 1) a change to the Resource initialization method, which is a big API/code change or b) a setter method which is ugly when this is a required instance attribute.