Deploy Development

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.

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!