This update contains state_migrations on `scipost.remark` and
 `scipost.{vgm_tables}`. This means the database scheme won't be
 altered but the migrations table which tracks all migrations done
 by the system will be updated to make sure the system knows how
 to handle the new apps. (Note the db_table option in the models of
 the new apps, this makes sure no db scheme migration is needed).

When doing the migration, the following will be asked:
"""
The following content types are stale and need to be deleted:

    scipost | newsitem
    scipost | motion
    scipost | nomination
    scipost | feedback
    scipost | vgm

Any objects related to these content types by a foreign key will also
be deleted. Are you sure you want to delete these content types?
If you're unsure, answer 'no'.
"""

One can anwser 'yes', the database won't be altered, no entries will
 be lost during this operation.

Due to a security fix visitors are not allowed to change their surenames.
 However, this was only fixed by appending HTML-tag 'readonly':
 1) It's still really easy to this change your surename by just removing
    this HTML-tag in your browser.
 2) The surename data wasn't sent so the processing form (due to a not required
    field) return the surename as an empty string.

Eventually this views should entirely be processed by a modelform ONLY. So no more
 assigning cleaned data to specific fields of the request.user.contributor!

Move and `state-migrate` news items away from
 the mighty `scipost` app.

Migrations are ready to be run without dataloss.
 If asked during `migrate` to alter stale FK field,
 run with anwser `no`! This is not stale, Django just
 thinks it is due to state migration of the new apps.

The settings environment has been changed to the preferable
 situation in which secrets are kept secret, but all settings
 are still tracked, even local settings. Use the updated readme
 file to get started again. Please track your settings, unless
 the settings really are secret!

Write tests and refactor html.

The url is based off of the DOI. Because the DOI is always the same,
making more than one factory instance crashes the detail page.

UnpublishedVettedCommentaryFactory does not have this problem,
as it has an empty DOI field and a valid (random) arxiv identifier.