- Replaced collection api: The "InstrumentedList" proxy is replaced with

- Replaced collection api: The "InstrumentedList" proxy is replaced with
  a proxy-free, decorator-based approach for user-space instrumentation and
  a "view" adapter for interaction with the user's collection within the orm.
  Fixes [ticket:213], [ticket:548], [ticket:563].
- This needs many more unit tests.  There is significant indirect coverage
  through association proxy, but direct tests are needed, specifically in
  the decorators and add/remove event firing.
- Collections are now instrumented via decorations rather than
  proxying.  You can now have collections that manage their own
  membership, and your class instance will be directly exposed on the
  relation property.  The changes are transparent for most users.
- InstrumentedList (as it was) is removed, and relation properties no
  longer have 'clear()', '.data', or any other added methods beyond those
  provided by the collection type.  You are free, of course, to add them
  to a custom class.
- __setitem__-like assignments now fire remove events for the existing
  value, if any.
- dict-likes used as collection classes no longer need to change __iter__
  semantics- itervalues() is used by default instead.  This is a backwards
  incompatible change.
- subclassing dict for a mapped collection is no longer needed in most cases.
  orm.collections provides canned implementations that key objects by a
  specified column or a custom function of your choice.
- collection assignment now requires a compatible type- assigning None
  to clear a collection or assinging a list to a dict collection will now
  raise an argument error.
- AttributeExtension moved to interfaces, and .delete is now .remove
  The event method signature has also been swapped around.