Clean up use of abstract base classes in the core-frontend API

[LewisGaul]

The current setup is quite general (good) but also quite confusing (bad!). Things could be simplified a bit, or at least made clearer in docs.

To summarise the current setup:

• AbstractController defines methods that correspond to user-driven events
• AbstractSwitchingController inherits the above but is intended to contain an active controller instance, with the ability to switch between different controllers (providing different functionality, e.g. 'game' and 'create')
• AbstractListener defines notifications that controllers may send for updating the GUI - listeners can be registered on controllers
• If you squint through MVC goggles, the model is stored in the concrete controller and the concrete listener is the view

The concrete implementation is as follows:

• api.Caller is a concrete instance of AbstractListener that serves to delegate to all registered listeners (instead of all controllers having to loop over their registered listeners, they just call methods on the 'caller')
• engine.BaseController is a switching controller, which is what's referenced by the frontend for passing on user interaction events
• engine.GameController is the standard game controller, the default active controller referenced by the base controller
• engine.CreateController is the 'create board' controller
• frontend.main_window.MinegaulerGUI implements the listener interface, and is registered on the base controller in __main__

Problems with the above:

• [x] Since there are multiple controllers flying around, when a new controller is created the already-registered listeners must continue to be used, leading to the confusing notif: Optional[api.Caller] init arg
  • This [exposed] concrete implementation of a listener in the api module feels very wrong
• [X] The implementations of the controller interface could be more cleanly separated from other controller logic [EDIT: I'm not sure about this actually]
• [ ] The implementation of the listener interface could be more cleanly separated form the actual GUI class (metaclass clash...)
• [x] There's probably a cleaner solution for delegating to an active controller than having this whole new abstract 'switching controller' class
• [ ] Needs documenting better

[LewisGaul]

Partially addressed by a5cffb780dc7927383ffc73138253e1d2e5c1fa7:

• Moved Caller class to be private (now _Notifier)
• Made the 'switching controller' the main abstract controller, moved the 'non-switching controller' base class to engine

[LewisGaul]

Things have moved around, or at least been renamed a fair bit since this issue was created. I don't feel there's an urgent need to tidy things up further, but I'm keeping the issue open for tracking the remaining two points:

• The GUI class could store the object implementing the 'listener' interface rather than being it (composition over inheritance)
  • See the minefield widget 'impl's
• Documentation