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 have kind of mixed feelings about this. Even though this separates the responsibility of lookup / execution order in the resource collection; it also makes the resource collection class harder to interact with. 

1. The fact that user needs to push the same object to two things while inserting (or during WRITE) but have a single READ interface is kind of confusing to me. It's pretty likely to forget to insert into the list or the set and get inconsistent results while reading.
2. I'm pretty sure `run_context.resource_collection` is heavily being used by external tools and formatters. Changing that is a significant backwards compat issue for the tools. So I'm heavily :-1: on that aspect. 

I think one way to achieve separation of responsibilities while maintaining the backwards compatibility is to still have the `ResourceSet` and `ResourceList` classes and make `ResourceCollection` class an orchestrator to READ / WRITE to the new classes.

This way we can keep the backwards compatibility, design a new interface for `ResourceCollection` (add new methods like `lookup_by_type()`, `list_by_type()`,  `execution_order()` etc...), add new methods and deprecate other methods to be removed in Chef 13. 

Of course this brings the question of do we want to make this change in Chef 12 then or can we do the minor fix of adding a new `insert_as()` method to remediate the current issue in Chef 12 and do this later?