Utilize an Abstract Class for GUI, TUI, and CLI

[n8marti]

I think this is a worthwhile idea. For the GUI nearly everything happens in a background thread, and the GUI window is the about the only thing that happens in the main thread.

• Each background thread basically has its own queue (if any information needs to be passed back to the GUI), its own event, and its own method to handle that event.
• The GUI starts the thread and its associated function.
• When the function is done it puts any needed information into the queue and then generates the event.
• When the event is generated in the thread it calls the associated method in the GUI, which continues the processing.
• If information is needed from the background thread, then this GUI method looks for that in the queue.

So if we use standardized names for the common features (progress indicators, status messages, etc.), then we should be able to streamline the code that uses these features.

[thw26]

A way to begin this would be to move our event and thread and queue code to its own module; this would let us treat it more like a library rather than a dialog-specific solution.

[thw26]

With the CLI code merged, we now have a minimal example of a Queue/Event model. We can reuse this to bring it to the TUI and GUI and thereby simplify their code greatly.