Future of swift

Decompose blackmisc and blackcore into smaller, more cohesive libraries.

The new libraries would lose the vestigial "black" prefix which is a point of confusion for new contributors.
By being smaller and more cohesive, they can be truly reusable and not tightly coupled to one specific pilot client.
- For example, another project can use our FSD and AFV implementations without being forced to include DBus and other irrelevant stuff.
- By this we try to ensure that our code has more longevity, attract collaborators, and create maximum value for the community.
This process of decoupling is also necessary for reducing complexity.
- We hope it will open up new opportunities, such as the possibility to create a new client building upon the core of swift.

"Module" means a header file and its corresponding .cpp file.
So far this has been done for the modules in the root directory of blackmisc.
I have used various ad-hoc scripts to detect cycles in the dependency graph, but none works 100% perfectly.
When a particularly difficult cycle is detected, one of several different refactoring patterns can be applied to break the cycle:
- I refer to the "levelization techniques" described in chapter 5 of "Large Scale C++ Software Design" by John Lakos:
  - Escalation, demotion, opaque pointers, dumb data, redundancy, callbacks, manager class, factoring, escalating encapsulation.
  - See also https://github.com/swift-project/pilotclient/issues/77#issuecomment-683468351
  - Examples of dumb data: 63e8de8f, b1185eb5
  - Example of demotion: ecac4bcb

The metaclass system (formerly the tuple system) can be used to rationalize a lot of propertyindex-related methods, but this is a lot of work.
This is made possible with C++17 support (especially constexpr lambda functions).
See also https://github.com/swift-project/pilotclient/issues/27

There is no need to switch between different simulators on the fly. This feature adds unnecessary complexity.
It is sufficient to allow the user to choose one simulator when they launch swift. To use a different one, they can restart swift.
We could drop the plugin system completely, and just ship a different swift executable for each sim.

Set up a standard configuration and model set by default. Keep the wizard for advanced users.
See also https://github.com/swift-project/pilotclient/issues/49
XSwiftBus could be included in the installer instead of being downloaded in a separate step.
- Another possibility is for the X-Plane plugin to be a stub that does nothing but load the "real" plugin as directed by the pilot client.
- The stub only needs to be installed in the X-Plane plugins directory once. The "real" plugin lives in the swift installation directory.
  - The loading can be done using libltld (cross-platform dynamic linker).
  - The client can send the path of the "real" plugin via simple network protocol:
    - The built-in UDP protocol of X-Plane;
    - Or JSON with a basic HTTP server (e.g. libhttpserver).

The datastore adds value, but swift should still be able to work without it, and not use it as a crutch.
As many features as possible should be able to work without the datastore. We should only use it for features that really need it.
If the datastore is unavailable, swift should gracefully degrade to an alternate mode with relevant features disabled.
We can't maintain it forever and we should aim to simplify it as much as possible to reduce the maintenance cost.

More streamlined UI with most common features immediately accessible. Less common features hidden in menus and pages.
Avoid grids of buttons. Use more icons in place of (or in addition to) text.
Inspiration may be taken from Drago's prototype.
Can be embedded in simulator? Consider other UI libraries?
Avoid business logic in UI code. Move it to the core.