Refactor into production-level deployment

[sveinugu]

The server currently runs in a single process/thread setup, using the run() method of Flask. From the documentation:

        Runs the application on a local development server.

        Do not use ``run()`` in a production setting. It is not intended to
        meet security and performance requirements for a production server.
        Instead, see :ref:`deployment` for WSGI server recommendations.

We need to improve the deployment of the augmentation server in order to serve it as a proper production server. This includes:

• uWSGI server
• Support for multiple threads, processes or both
• Ontologies dict needs to be read in only once, at startup, and work as a resource for the other threads/processes.
  • Several possible solutions:
    • Separate database process
    • Separate Python process that support multiple threads/processes (e.g. https://stackoverflow.com/questions/28423069/store-large-data-or-a-service-connection-per-flask-session/28426819#28426819).
    • Separate Flask process with own API (support multiple simultaneous connections)
• Ontology data should be updated to new versions regularly, hence the ontology reference data is not considered immutable. One can for instance store last modification date of each ontology file and then regularly check whether the remote file has been modified.
• Keep support for local disk storage of ontology files to improve launch speed (used for unit tests today)
• Keep support for running tests without having to deploy a server.
• Assume a docker compose setup will be a natural choice. But should still run this together with the TrackFind service, at least for now.

Create sub-issues as needed. Not priority for v2.0, but soon after.