The personal page has an extreme database load. The number
 of database queries is heavily dependent on the number of
 objects loaded into the views such as own_comments, etc etc.
 On my almost-empty local database this resulted in 94 queries
 in a single view request with a significantly long loading time!

This is a quick and dirty, first improvement. Splitting the different
 tabs to different routes or dynamically load the tab content when
 opening seems a best option after all.

The select_related method reduces the database load
 by a factor of +/- 5 on the list view.

The context processor for the old search form is removed to
 be replaced with a general HTML tag coded in the template.

'Bootstraped' the search result page.

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.

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.

Fix bug that allows a forged post request to create a comment,
while the submission is not open for commenting.