This address is set with the new `BATCH_NOTIFICATION_EMAIL` config
setting and defaults to the value of `EMAIL`.

Caching of transcript protein links received from the NCBI Entrez
service is a typical use case for Redis. This implements this cache
in Redis and removes all use of our original database table.

An Alembic migration copies all existing links from the database to
Redis. The original `TranscriptProteinLink` database table is not
dropped. This will be done in a future migration to ensure running
processes don't error and to provide a rollback scenario.

We also remove the expiration of links (originally defaulting to 30
days), since we don't expect them to ever change. Negative links
(caching a 'not found' result from Entrez) *are* still expiring,
but with a longer default of 30 days (was 5 days).

The configuration setting for the latter was renamed, yielding the
following changes in the default configuration settings.

Removed default settings:

    # Expiration time for transcript<->protein links from the NCBI (in seconds).
    PROTEIN_LINK_EXPIRATION = 60 * 60 * 24 * 30

    # Expiration time for negative transcript<->protein links from the NCBI (in
    # seconds).
    NEGATIVE_PROTEIN_LINK_EXPIRATION = 60 * 60 * 24 * 5

Added default setting:

    # Cache expiration time for negative transcript<->protein links from the NCBI
    # (in seconds).
    NEGATIVE_LINK_CACHE_EXPIRATION = 60 * 60 * 24 * 30

Previously transcript-protein links were assumed to always be
indexed by transcript, and cached entries were allowed to have
a `null` protein (meaning caching the knowledget that there is
no link for this transcript).

Now we can cache links in both directions. Both transcript and
protein are allowed to be `null` (but not at the same time),
and the protein column has a new unique constraint.

The Werkzeug reloader is disabled by default due to a bug with
using it in combination with `python -m mutalyzer.entrypoints.website`.

https://github.com/mitsuhiko/werkzeug/issues/461#issuecomment-139369694

By default, the first request to the SOAP service will trigger a
build of the WSDL document, using the context (service location)
from that request. For example, if the first request is on
`http://localhost/` and subsequent requests are on
`https://mutalyzer.nl/services/`, they will not have a valid WSDL
document.

This is actually what we do on our production infrastructure,
where the service is tested (on localhost) after it has been
started.

The fix is to force a build of the WSDL document and specifying
the location to use.

http://spyne.io/docs/2.10/reference/server.html#spyne.server.wsgi.WsgiApplication

This is quite a large commit, touching many things related to developer
documentation. It is all focussed on getting as much of this as possible
into the new Sphinx-based documentation.

Some highlights:

- Start Sphinx-based developer documentation, including fairly complete
  instructions for installation and configuration.
- Remove epydoc API docs.
- Rework some docstrings to conform to reStructuredText, so they can be
  used in the API docs generated by Sphinx.
- Move all of the top-level text files to reStructuredText so they can
  linked from the Sphinx-based docs and for consistency.
- Remove many obsolete things from the extras/ directory, including old
  installation scripts and migrations.

Many of the installation related documentation and scripts are removed
or adapted in light of the new automated deployment using Ansible.