Clean up public API

[dirkwhoffmann]

This is a prerequisite for #781.

Implementing run-ahead requires the emulator to be aware of all state changes coming from outside (key presses, joystick movements, etc.). Once this is assured, the run-ahead instance can run independently of the primary instance as long as there is no external event.

Right now, the GUI can access all public functions of any component. This needs to be changed. All calls from outside (GUI) must be routed through a well-defined public API.

The existing API (as defined, e.g., in the ObjC proxy) isn't nice. It has grown over time and lacks consistency. Thus, this is an excellent time to clean up the public API at this point.

Maybe adopting some design ideas from the Libretro API is a good idea. I don't have plans to make VirtualC64 a libretro core myself, but it would be nice to have a public API that makes it easy to turn VirtualC64 into a libretro core at a later time.

[dirkwhoffmann]

First milestone reached: All accesses from the GUI side are now routed through the public API, represented by the new VirtualC64 class.

The new top-level architecture looks as follows:

Next step: Clean up the public API

[dirkwhoffmann]

The new architecture is emerging.

To reduce the number of entry points into the emulator, VirtualC64 got a command receiver. For every event-like notification (joystick pulled, key pressed, etc.) a command is sent to the command queue via put. The command queue maintains a ring buffer storing all incoming commands. All pending commands will later be processed by the emulator core in it's update phase.

Overall, the new architecture looks like this: