Decouple Script from Zenity

[thw26]

Or make CLI something like a first class citizen. The ground work is now laid for this in #98.

The script should possibly be smart enough to check for Zenity independently, and, if not found, continue the install without erroring and requiring Zenity to be installed.

This should implement an abstraction for dialog and whiptail for OS portability. Will require determining which one the user has installed, if neither, then check for zenity, and it not, report an error to the user. Programming at least one of these and implementing the latter at another time would be acceptable for the purpose of this issue.

This will also require determining if the script is launched from the CLI or not. If it is not from the CLI, the script should check for zenity and error if zenity is not installed.

We should also consider further abstraction for pure bash for the sake of #149.

• Abstract script messages (Error messages #151, Add logos_info() and logos_warn() #152)
• Abstract gtk_question, gtk_continue_question
• Abstract zenity --progress
• Abstract radiolist, used in, e.g., chooseProduct
• Abstract gtk_download
• Move all message communication to abstract classes (i.e., all echo/printf messages to the CLI should be edited to use logos_info or cli_msg (e.g., here).)
• Create a CLI alternative for gtk_question, gtk_continue_question, zenity's radiolist, gtk_download

This will also likely require that the script only executes one of these at a time, otherwise the script would have to monitor both functions. As the easiest solution, the abstract functions should likely receive a required variable to indicate which communication method to use with the user. e.g., logos_error(DIALOG) {…}. cf. winetrick's implementation of auto-detecting GTK or QT.