Fix query bug in update transcript-protein links

Test database migrations

Push to release branch requires passing status checks

Release 2.0.12

Fix transcript protein link query

Bi-directional cachinig of transcript-protein links

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.

Fix off-by-one in slicing chromosome by gene name

The original code would always add one extra downstream base to
the slice (for genes on the forward and reverse strand).

Correcting this implies that cached slices will not be used by
new queries requesting the exact same gene and number of upstream
and downstream bases, effectively invalidating them.

However, most existing cache entries affected by this bug will be
on GRCh37/hg19, whereas current slices by gene name will yield
GRCh38/hg38 slices.

The only cache issue I see is trying to use existing cache
entries created by slicing by gene name, by re-slicing by
explicit coordinates instead of gene name. To get the old cache
entry one would have to add an extra downstream base.

PEP-8 rewrite except for public function names.

Show diff for variant protein from non-reference start codon

The alternative variant protein sequence translated from a
non-reference start codon (created by the variant), was not
color-diffed as normal variant protein sequences are.

In the process we also rename the `oldprotein` and `newprotein`
fields in the output object to `oldProtein` and `newProtein` to
be more consistent with other field names.

Translate alternative start to M, also in variant

In the case of an alternative start codon (in the reference CDS),
protein changes were not visualised. This is fixed and a WALTSTART
warning is also issued.

Also, if a new non-reference start codon is created by the variant,
visualise this as such.

In case of an alternative start codon, the variant CDS was not
translated to a protein starting with M. This caused the protein
description machinery to conclude a variant affecting the start
codon, hence reporting `p.?`.

We fix this by always translating the start codon to M (except
when the variant actually affects it).

Example: `NM_024426.4:c.1107A>G` (a synomymous mutation) should
yield `NM_024426.4(WT1_i001):p.(=)`, not `p.?`. The start codon
for that protein is `CTG`.

Disable Travis-CI notifications on Slack

We see the Travis-CI status in GitHub pull requests anyway.

Add Baker's yeast (SacCer_Apr2011/sacCer3) assembly

Using the Werkzeug reloader is configurable

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

Fix service location in SOAP WSDL document

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

Only create database tables once

If at least our assemblies table exists, we assume the Alembic
migrations will deal with the rest.

Documentation updates