setslice of ``[0:0]`` correctly, which in particular could occur
when using ``insert(0, item)`` with the association proxy.  Due
to some quirk in Python collections, the issue was much more likely
with Python 3 rather than 2.  Also in 0.8.3, 0.7.11.
[ticket:2807]

before we do the pop() test.
- make clear()/pop() test unconditional

ideas in general:
  - pypy2.1 w/ sqlite3 is the first DBAPI we're seeing returning
    unicode in cursor.description without being py3k.  add a new on-connect
    check for this, if we get back a u"", just don't do description decoding,
    should be OK for now.
  - the set tests in test_collection were assuming the two sets would be ordered
    the same when it tested pop(), can't really assume that.
  - test_serializer gets worse and worse, pickle is just not really viable here,
    ding out pypy
  - pypy2.1b2 seems to allow cursor.lastrowid to work (or we changed something?)
  - pool._threadconns.current() is a weakref, it can be None
  - another one of those logging.handlers imports

- went through examples/ and cleaned out excess list() calls

method, which fires off each time the collection is associated
or de-associated with a mapped object - the decorator
was not tested or functional.  The decorator method
is now named :meth:`.collection.linker` though the name "link"
remains for backwards compatibility.  Courtesy Luca Wehrstedt.
[ticket:2653]

collections, mainly that the usage of the @collection decorators
will now honor the __mro__ of the given class, applying the
logic of the sub-most classes' version of a particular collection
method.   Previously, it wasn't predictable when subclassing
an existing instrumented class such as :class:`.MappedCollection`
whether or not custom methods would resolve correctly.
[ticket:2654]

- The undocumented (and hopefully unused) system of producing
custom collections using an ``__instrumentation__`` datastructure
associated with the collection has been removed, as this was a complex
and untested feature which was also essentially redundant versus the
decorator approach.   Other internal simplifcations to the
orm.collections module have been made as well.

become an externally usable package but still remains within the main sqlalchemy parent package.
in this system, we use kind of an ugly hack to get the noseplugin imported outside of the
"sqlalchemy" package, while still making it available within sqlalchemy for usage by
third party libraries.

[ticket:2409] whereby column_mapped_collection
used against columns that were mapped as
joins or other indirect selectables
would fail to function.

Here, the serialize use case has gotten very complex since to
really target a column we'd need the root MetaData object,
then if we're hitting Alias objects and such there's really
nothing to hold onto.  Short of building a system where
Column objects have some kind of master hash identifier that
is consistently generated, the way this works can't really
suit every case - much easier would be to change the mechanics
of collections.py to make available the Mapper to the
collection adapter when it's first invoked.