major GTK UI rewrite: use a separate execution thread

 * the execution thread does not block the main thread (with
   the main loop).
 * therefore if SciTECO executes a long-running macro,
   the UI stays "responsive".
 * also this allows us to handle ^C interruptions.
   This is part of the solution to #4 for GTK+ UIs.
 * to speed up execution and avoid frequent UI redraws
   (now that we run concurrently, there are even more redraws),
   the view change is applied only after key presses.
 * also we freeze all UI updates on the view during SciTECO's
   key processing.
 * Closing the window, requests a graceful execution thread
   shut down. This may later be extended to allow programmable
   window close-behaviour using a special function key macro
   (e.g. mapped to the "Break" key).

0 files changed, 0 insertions, 0 deletions