Automatic upgrade step discovery

:construction:

As discussed in #52, this pull request implements a new ``upgrade-step:directory`` directive for automatic discovery and registration of upgrade steps.

## Goal

The details are discussed in #52.
The primary goal is to reduce the merge conflict potential of concurrently created upgrade steps.
This is attempted by

- not using auto-incremented version numbers; timestamps are used instead
- using less ZCML which can conflict; upgrade steps are automatically discovered and registered within a directory
- removing the version in the metadata.xml, which may conflict.

## Implementation overview

- A directory containing upgrade step can be registered using the new ``upgrade-step:directory`` directive.
  Example:
  ```xml
  <configure xmlns="http://namespaces.zope.org/zope"
             xmlns:upgrade-step="http://namespaces.zope.org/ftw.upgrade">
      <include package="ftw.upgrade" file="meta.zcml" />

      <upgrade-step:directory
          profile="my.package:default"
          directory="upgrades"
          />
   </configure>
   ```

- The directory is scanned, detected upgrade steps are chained and registered automatically.

- Each upgrade step is a directory with a leading 14-digit timestamp in the name; the directory contains an ``upgrade.py`` and may contain generic setup profile files:

  ```
  - my/package/
    - upgrades/
      - 20141122083059_do_something/
        - upgrade.py
        - actions.xml
  ```

- The timestamp (e.g. ``20141122083059``) acts as target version of the profile.

- The upgrade step directory is automatically registered as separate generic setup profile, e.g. ``my.package:default-upgrade-20141122083059``.

- The ``upgrade.py`` simply contains an ``ftw.upgrade.step.UpgradeStep`` class, which may import the associated generic setup profile with ``self.install_upgrade_profile()`` (the associated upgrade step profile name is automatically chosen).


## Details

- Since I've implemented the ``install_upgrade_profile`` method, I've also added a new ``handler`` option to the already existing ``upgrade-step:importProfile`` directive as discussed in #47; the implementation regarding associated generic setup profiles is shared.

- Since the upgrade steps are now longer ordered by an increment number but by a timestamp, it is possible that "older" upgrade steps are merged later than "newer" upgrade steps (longterm branches problem). In order to detect those, the installed upgrade steps are tracked per Plone site. Those "orphans" are highlighted in the upgrade view (see screenshot). The disadvantage is that in the worst case it may first be discovered when upgrading a production site; but I think the advantages with the automated discovery outweight this disadvantage.

![bildschirmfoto 2014-10-21 um 21 17 15](https://cloud.githubusercontent.com/assets/7469/4797867/cebd0396-5e0e-11e4-8d87-79ba4b609d22.png)

- I'd like to have a command line tool for generating upgrade steps, especially for generating the timestamp. I've not yet thought about that, I think it diserves a separate pull request.

- :construction: I've not yet documented this feature in the readme. I'm tempted to rewrite the documentation with spinx / autodoc :wink:


## Discussion

This is a first working implementation. I'd love to have some feedback @maethu @buchi @deiferni @lukasgraf @phgross and anyone interested :wink:
When? I feel this is one of the more magical parts of the implementation, and could use a tiny bit more explanation.