Add package-namespace MOM.DBW.SAW
Improve `Id_Entity` attributes, support surrogates

* Add explicit attribute `MOM.Id_Entity.type_name`

  - Accessible through instance and class.

* Add explicit attribute `MOM.Id_Entity.pid`

  - Based on new attribute type `A_Surrogate`

  - Add support for surrogate key attribute

    Each e_type now can have one additional surrogate key
    attribute besides `pid`. That surrogate is
    auto-incremented and unique for the responsible e_type.

  - Add guards against redefinition to `Surrogate`

* Make the default value of the attributes ``electric``
  and ``x_locked`` accessible through the class; for
  instance, ``scope.PAP.Person.electric`` now returns
  `False` instead of an attribute descriptor.

* Add properties `type_name` to `M_E_Type` and `electric`
  and `x_locked` to `M_E_Type_Id`. These properties return
  a value instead of the attribute descriptor and forbid
  the change of `type_name`, `electric`, and `x_locked`
  for essential classes.

  Add ``MOM.Id_Entity.__setattr__`` to protect attribute
  descriptors returning the attribute default when accessed
  by the class (for these, Python allows assignment to
  instances without going through the descriptors
  ``__set__``).

* Include all `q_able` attributes in `AQ`.

  Add new flag `q_able` to MOM.Attr.Type and MOM.Attr.Kind.
  Allow all `q_able` attributes for query restriction and
  sort order.

* Factor `is_attr_type`

* Dry class names of `MOM.Meta.M_Attr_Type`

* Use `db_meta_data` in `consume` of `migration`

* Prepare surrogate migration

* Add `DET`, `DET_Base`, `DET_Root` for attributes

  - Plus `det_base` and `det_root` for attr-type instances
    (`det` itself would be identical with `e_type`).

  - The ``DET_Root`` is the E_Type that introduces an
    attribute, the ``DET_Base`` is the E_Type from which a
    redefined attribute is inherited, the ``DET`` is the
    E_Type that defined the attribute in question.

* Fixed dynamic documentation properties, e.g.,
  `description`, for auto-derived polymorphic associations.
  Before, the first level children would get the proper
  documentation, but the further level children didn't.
Implement new DBW package SAW

MOM.DBW.SAW is a database wrapper for databases accessed via
sqlalchemy. It contains a sub-package for each RDBM
supported (currently PG for PostgreSQL and SQ for SQLite;
plus a rudimentary MY for MySQL).

SAW supports:

* Polymorphic queries computed by the database itself.

  The old package SAS needed to combine the results of
  several database queries in Python which is quite
  inefficient if sorting and limiting is involved.

* Transitive queries of attributes of joined tables.

  This allows query expressions like::

    Q.regatta.event.date.start > "2009/05/21"

    Q.person_links.person.last_name == "tanzer"

* Composite binary expressions.

  For instance::

      Q.person.lifetime == ("2013/07/15", ) --> T.lifetime__start = ...

      Q.person.lifetime == ("2013/07/15", "2013/07/21") ->
          T.lifetime__start = ... AND T.lifetime__finish = ...

* `order_by` for id-ref and composite attributes expands to
  the column names of the joined or nested attributes.

  For instance::

      Q.person   --> (TP.last_name, TP.first_name, TP...)

      Q.lifetime --> (T.lifetime__start, T.lifetime__finish)

* Automatic use of aliases for joins triggered by attributes
  to allow multiple joins to the same table.

* Bound variables for parameterized queries.

* Promotion of column names to boolean where necessary.

  For instance, a filter condition is expanded automatically
  to the SQL expression appropriate for the column type in
  question, i.e., foreign keys, non-nullable strings and
  booleans use different expressions.

  For instance, the query expression `Q.person` expands to::

    pap_person_has_account_1."left" IS NOT NULL

* Queries of the change objects

  - related to specific essential objects,

  - caused by a specific user,

  - filtered by time of change.

* Use of database-specific data types for database columns.

  For instance, SAW.PG uses `CIDR` for IP addresses, while
  `SAQ.SQ` uses a number of synthetic columns for IP
  addresses. Both backends support the same queries, with
  PostgreSQL doing most of the work for `SAW.PG`, while
  `SAW.SQ` implements IP address comparison with complex SQL
  expressions over the synthetic columns.

* Use of save_points for SAW.PG to allow unrolling just the
  last statement while keeping the rest of the pending transaction.
Remove MOM.DBW.SAS backends
Optimize EPK-unique checks in HPS
Do not use sequence tables in SAW for pid, cid

SAW.Sequence used to use a separate table for each sequence to allow
recovery of the max value even after rollback and delete operations.
This causes a massive performance hit for PostgreSQL.

Now, the sequences for `pid` and `cid` don't use a separate table for
the sequence. `max_pid` and `max_cid` are now implemented as queries
over the table for `MOM.Id_Entity` and `MOM.MD_Change`. This increases
performance for the price of backend-specific values after rollbacks
(which mainly hurts in the tests).
Merge branch SAW: new SQLAlchemy wrapper for MOM
Change `instance` to use `relevant_roots`

The generic query used until now is very inefficient compared to using
`Type.relevant_roots`.