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

Follow-up to #387, fixes #388

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.