Fix data migrations for Reference.source

Due to a bug in the data migrations for the new `Reference.source`
column introduced in #387 and #392, the start position for references
created as a slice was used as both start and stop position in the new
column for storing this data.

This commit fixes these migrations and on top of this adds a new
migration which corrects any values set by the old migrations (in case
they were run before this fix). The original columns for these values
have not yet been dropped, so no data has been lost.

Thanks @ifokkema for reporting this issue.

Fixes #393

Add NOT NULL constraint on Reference.source

Follow-up to #387, fixes #388

Release 2.0.19

Consider accession version in getGeneName

Fixes #385

Track source for reference files

Previously, the original source for a reference file was implicit:

1. If accession number starts with `LRG_`, it came from the LRG FTP
   archive.
2. If a download URL is known, it was downloaded from there.
3. If slice data is known, it was sliced from the NCBI.
4. If a GI number is known, it was downloaded from the NCBI.
5. Otherwise, it was uploaded.

In preparation for the removal of GI numbers (#349), this had to be
revisited. We now store the source explicitely in a new `source` field
on the `Reference` model. If additional information is needed to
re-fetch the file from this source (e.g., download URL), this is stored
in a new `source_data` field (always serialized as a string). This
scheme should be both more explicit and more generic.

Document database migrations

Some basically empty pages are effectively obsolete and better to be
removed alltogether.

Seems that our mocking strategy in the Sphinx configuration causes
infinite recursion since version 1.1.0 of the mock package.

This fix follows [1] and we hope this still works.

[1] https://github.com/sbusard/pynusmv/issues/2

Fix reference file loading by url

For some reason there is no `Content-Type` key in the object returned by
`urllib2.urlopen().info()`. However, the `gettype()` method seems to
work.

I have no idea if this code ever worked, and if so, why. Also, the check
for the `text/plain` content type is pretty bogus in my opinion. A
server can say whatever it likes and valid GenBank files may well be
served with different content types.

Mention max column length in batch submit error

Slightly better message for some unsupported input

This is not perfect yet, but a slight improvement for input variants of
a type we don't support. Fixes for example #375

Release 2.0.18

Update link to LRG mappings issue

Slice by gene fixes

String formatting of the message was broken by #76 (`s.format()` needs
separate arguments, not a tuple, as opposed to `s % ()`.

We also prettify the message by creating a comma-separated list of
aliases.

For example, CLN3 in Dog doesn't have NomenclatureSymbol set, but it
does have Name.

Update examples and HGVS links

Remember optional argument for dup during parsing

This enables checking the argument of a dup variant, e.g., checking if
the `T` in `g.45dupT` is correct.

Fixes #143

Fix description extractor citation