Druid reusability strategy

Nobody has claimed this yet.

I would like to open a discussion and then settle on a strategy for druid on what sort of reusability guarantees we have. There's also a sub-question of whether this will apply to both `druid` and `druid-shell` or if those two will diverge in strategy.

Here are some obvious levels of reusability:
1. Reuse druid in a different process.
* The use case being that an end-user wants to run either multiple instances of a druid app or even has several different druid apps and wants to run them concurrently.
* To achieve this druid either can't depend on any OS-wide global state that another process would conflict with, or has to be smart about it and be able to reuse state initialized by another process plus has to be sure not to do any cleanup while other processes are still running.

2. Reuse druid in the same process sequentially, that is after one `AppLauncher::launch()` has returned the application can perform a new `AppLauncher::launch()` (perhaps on the same `AppLauncher`, but requiring a new struct would be fine too) and everything would work.
* The use case being a long running process that occasionally needs a GUI but doesn't want druid to consume any resources most of the time.
* To achieve this druid needs to do proper cleanup of global state or be smart about reusing previously initialized state.

3. Reuse druid in the same process concurrently, that is several `AppLauncher::launch()` loops running at the same time in different threads.
* I don't have great use cases for this one, but perhaps having a "utility bag" type application which contains otherwise standalone druid apps as features. Perhaps to support gradual migration from one druid major version to another so that legacy code can run unmodified while new features in new windows are being developed with a newer druid.
* To achieve this druid either can't depend on any global state or it has to be smart about it with reference counting.

There might be other useful levels which I'm missing. Feel free to describe them.

Whichever level we choose, it should be documented so that it's clear. Assertions should be added to the code so that druid would fail with a clear error message fast, instead of eventually running into some random collision like now. All past & future code should be reviewed to ensure it works with the chosen level.

Personally I think level 1 (concurrent processes) is a must have. The other levels might require too much work for too little gain. The level 2 long running process use case could launch a sub-process when the GUI is needed, which would be fine on all non-embedded platforms I imagine.

Start by reviewing AppLauncher::launch and the global-state behavior in both druid and druid-shell. Decide which process or same-process reuse guarantees to support, then document the strategy, add clear assertions for unsupported reuse, and review existing and future code against it.

Written by the indexing model from the issue text.