Run both servers as standard

[CasperWA]

In discussion with @shyamd (and @ml-evs) we've decided running sh run.sh should result in both the regular implementation as well as the index meta-database implementation should run.

Each implementation may be run separately by passing either regular or index to run.sh.

As before, run.sh also accepts the parameter debug.
run.sh may be called with the parameters in any order.

Suggested behavior: If both regular and index parameters are passed, it will start both servers, i.e., it will be equivalent to not passing any of these parameters.

This will have the "happy" side effect of having both implementations on Heroku, theoretically. We should look into proper port-forwarding.

[CasperWA]

Trying this out is giving me some issues, since I have to start the servers in the background, I am having trouble stopping them again. It may need a separate file to kill the processes or similar. I've found that one can send a QUIT signal to uvicorn, which should close them down nicely. See here. But I'm having trouble making it work.

I think I will leave this for now - someone else is welcome to give it a try, if they wish to, my work can be found in the fix_238_run_both_servers_as_standard branch.

[CasperWA]

Highlight instead the index meta-database and Docker instances in the documentation.

[CasperWA]

This will be possibly anew.

On slack we have agreed to implement the index meta-database as a "part" of the regular server (under the endpoint /index/v<MAJOR>/links and /index/v<MAJOR>/info).
This will be an "opt-in" solution based on a configuration boolean in the likes of include_index_api.

[CasperWA]

Re-closing this, since the new opportunity to host an Index Meta-Database under Materials-Consortia/providers, this is no longer necessary.

The original issue here may however still be implemented, but at this point the first closing reason will be re-iterated: Highlight instead the index meta-database and Docker instances in the documentation.

[CasperWA]

This piece of FastAPI documentation is potentially quite interesting for handling multiple databases with separate schemas and more.