Refactor configuration options

Janeway currently supports 3 main mechanism for setting up configurable items.

• Django `settings handler: This is a python module that can declare all caps variables and will be lazily loaded once when the request handler is first fired up. Some 3rd party libraries are making use of specific names declared here. (this has recently been skimmed down by #582 )

• model attributes across "site" models (i.e. press.models.Press, journal.models.Journal). These configurable options are persisted in the DB and loaded up per request. They can be modified by the users. moved to #3528

• The core.Setting* models: These configuration types allow registering typed settings (text, char, number), can be combined into logical groups, are translatable (even non-text settings) and their value is unique per journal.

As it currently stands there is a lack of consistency in terms of which mechanism is suitable for a given config item. We should review them and consider which mechanism is the most appropriate for each setting as well as enforce some rules moving forward.

Start by reviewing the Django settings handler, the site models formerly used for configuration, and the core.Setting* models described in the issue. Compare how existing settings are declared, persisted, loaded, typed, grouped, translated, and scoped per journal. Done means documenting or applying a consistent mechanism choice and clear rules for future configuration items.