[FEATURE] Remote Control API

There are so many use cases which require projectMSDL to be controlled by external events, devices or a remote PC, that it makes sense to implement a remote control API. This API should be able to perform any task which can be achieved via the UI, like changing settings, playback control, listing/changing audio devices and editing preset playlists on the fly.

Other inputs for controlling the preset playback, e.g. via MIDI events, can then be implemented via the API instead of adding all the use-case specific functionality directly into the UI. This will also make it possible to reconfigure those external inputs at runtime without visually disturbing projectMSDL, as the UI doesn't have to be opened.

The API should use a protocol which is easy to use either from a website or any custom application. There are three general ways to implement it technically:

• JSON RPC via HTTP/1.1: The most basic API possible, used in many web applications. Uses simple request-response calls from the client to projectMSDL. Ideally using Open API 3 to create the specification.
• Bi-directional communication via Websockets: Allows communication in both directions, but Websockets are not supported by some HTTP client frameworks.
• gRPC via HTTP/2.0: A mix of the above, using HTTP2 streams. By default uses a request-response mechanism, but clients can also subscribe to specific "events" on the server to be notified if something changes.

Currently, the only events which would make server-side events necessary is automatically switching presets (to get the new preset name) and possibly a change of the current audio device. In the first case, this info could simply be polled every second or so if needed. That would make the JSON RPC API the preferred one for a first implementation. The other ones could also be done later if there's need.

Authentication should use the standard OAuth protocol.

For environments which require it, e.g. open networks or even the internet, projectMSDL should also support using HTTPS. In this case, the user has to supply the proper SSL keys and certificates, generated via OpenSSL or a compatible tool.

No files, tests, or entry points are named. Start by resolving the API protocol, supported UI operations, authentication, and HTTPS requirements described in the issue. Done would require an agreed scope and a complete remote-control API implementation rather than a single isolated change.