implicitly initialized to None via first access; this action,
which has always resulted in a population of the attribute,
now emits an attribute event just like any other attribute set
operation and generates the same kind of history as one.  Additionally,
many mapper internal operations will no longer implicitly generate
these "None" values when various never-set attributes are checked.
These are subtle behavioral fixes to attribute mechanics which provide
a better solution to the problem of :ticket:`3060`, which also
involves recognition of attributes explicitly set to ``None``
vs. attributes that were never set.
fixes #3061

scenario, where an INSERT/DELETE can be turned into an UPDATE.
In this situation, a many-to-one relationship set to None, or
in some cases a scalar attribute set to None, may not be detected
as a net change in value, and therefore the UPDATE would not reset
what was on the previous row.   This is due to some as-yet
unresovled side effects of the way attribute history works in terms
of implicitly assuming None isn't really a "change" for a previously
un-set attribute.  See also :ticket:`3061`. fixes #3060

of cascading a natural primary key update will succeed
even if the key is composite and only some of the
attributes have changed.
[ticket:2665]

- break out key mechanics of loading objects
into new "orm.loading" module, removing implementation
details from both mapper.py and query.py. is analogous
to persistence.py
- some other cleanup and old cruft removal

* allow_null_pks mapper() argument
(use allow_partial_pks)

* _get_col_to_prop() mapper method
(use get_property_by_column())

* dont_load argument to Session.merge()
(use load=True)

* sqlalchemy.orm.shard module
(use sqlalchemy.ext.horizontal_shard)

persistence.py - Mapper loses awareness of how to emit INSERT/UPDATE/DELETE,
persistence.py is only used by unitofwork.py.  Then break each method out
into a top level with almost no logic, calling into _organize_states_for_XYZ(),
_collect_XYZ_commands(), _emit_XYZ_statements().