Redesign the GUI

[noryb009]

After #15, there is no need for the frontend and backend to be split into two separate processes. Moving them into the same process (probably in separate threads, with a new backend thread created for each task) would have some benefits:

• It would allow removing the awkward message passing over pipes, instead doing simpler communication between threads.
• The front end would have admin privileges, allowing issues such as #12 to be trivial, instead of needing to pass messages to the backend.
• There is less possibility of a one of the two processes dying while the other lives. Currently, if the frontend dies, the backend might sit in the background indefinitely, while if the backend dies, the frontend may appear to be unresponsive.
• lickdir_t can be more complex, allowing the use of pointers, lists, etc.

Since almost all of the GUI code would need to be refactored, it would probably be beneficial to completely rewrite it. This would include:

• Changing the GUI toolkit or language. This can either allow Windows 9x support (#6), or it can be decided a Windows 9x GUI is not worth the effort. I'm leading towards the latter, because I have not received any feature requests for 9x support. In that case, it might be possible to use another toolkit, or even another language.
• Allowing a CD/directory to be selected for #20.
• A redesign of the architecture. The current architecture focuses on the backend taking simple commands. A new architecture could give the backend a scenario or list of commands, with the frontend simply providing feedback to the user.
• More features. #4 requires a dropdown of distros (which could currently hold fatdog to activate its distro-specific code). #12 would be trivial to add. #16 would be possible with an options dialog. #11, and other tools, could be more visible.

[noryb009]

Before this is completed, these issues should be looked at or resolved:

• [ ] #4, investigate adding more distributions. If other distributions are supported, the GUI might need extra features to support them.
• [ ] #5, internationalization. It would be easier to think of internationalization from the beginning than adding it in later.
• [x] #7, type safety in lists.