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.
I think there is a ton of value in not changing the ResourceCollection interface, at least until Chef 13.  My issue is that there are currently 2 different write methods that are storing data in _completely_ different formats.

The first write method is for storing the ordered list of resources - `insert(resource)`.  This has many aliases but they all write to this ordered list of resources.  The only parameter the caller supplies is the Resource instance.

The second write method is for storing the unique set of resources, keyed (currently) by resource type and resource instance name.  EG, `package[vim] => Resource::HomebrewPackage`.  The interface for this method is `insert_as(resource, resource_type, instance_name)`.  The caller must supply the Resource instance, the resource_type (`package`) and the instance name (`vim`).

There are times that callers want to [insert an ordered resource](https://github.com/opscode/chef/blob/tball/bsd_package_name/lib/chef/provider/deploy.rb#L379) but do NOT know how their resource was declared.  I think there are a couple ways we could handle this:

1. Store in the resource instance what type it was declared as.  From my above example, the `Resource::HomebrewPackage` would know it was declared as `package[vim]`.  But if we do this, I think we should pass it in as a required constructor arg to the Resource class.  Then the Resource can tell the ResourceCollection how it was declared, what it provides AND what class it actually is.
2. One write method on ResourceCollection - `insert(resource, resource_type=nil, instance_name=nil)`.  If the type/name are nil default them to resource class and resource name.  This one method would write to the ordered list AND the unique set.  But this leaves us in our current pickle, where the FreebsdPackage instance has no idea its resource was declared as `package[vim]` so it does not pick up notifications correctly.  UNLESS the only time we would not have the type/name are places like that deploy.rb script, where it (possibly) does not matter if they are entered into the set incorrectly.  I would need to get some feedback from people more familiar with the code base to determine if this is safe.
3. I thought about leaving both write methods on the ResourceCollection class, and having each method only control one data set.  IE, `insert` would control the ordered list and `insert_as` would control the set.  But then callers still need to use 2 write methods to setup the ResourceCollection correctly, and there is no information that tells why `insert` and `insert_as` are different.  Thats why I opted to expose the guts of the ResourceCollection for writes but not reads - I thought writes were too confusing without it.

I would love to talk about these options - maybe there is something I am not considering.