Bug/Issue description: Ctrl-C issue with GLI on Windows

Only on Windows: when you run GLI from the DOS prompt, Ctrl-C doesn't terminate GLI, whereas it would other Java applications (graphical or otherwise).
Pressing Ctrl-C when GLI is open has no effect, until you exit GLI normally. Then the DOS prompt finally notices that you had pressed Ctrl-C.
On Linux, and as should also happen in Windows as it does in other Java applications, a Ctrl-C should result in application terminating, with the shutdown hook being called first. Noticed this issue when testing the newly added ShutDownHook in Gatherer.java.

The problem has been tracked down to adding the Tabbed panes to GLI. In particular, Download, Gatherer, Enrich and Create panes are problematic. When these panes are not added to the Tabbed Pane, Ctrl-C works to immediately end GLI on Windows, rather than the Ctrl-C signal only being noticed after you quit GLI the normal way.

When inspecting the Download Pane's issue, the problem is tracked down to adding any GUI controls (like testfields) into the pane. Even adding a single simple textfield is enough to make Ctrl-C stop working properly.

This debugging version of the code is now in the state where problematic panes are not added except for the Download pane. DownloadPane.java was further inspected, and the problem with it tracked down to doing an add() on its JPanel to add GUI controls on it. Adding even a single control makes the difference between Ctrl-C being immediately effective and not working immediately anymore. 

After investigating further, DownloadPane.java is currently in the state where we don't run a perl process to work out what Download methods (Web, OAI, etc) we have, and this is back to being hardcoded in Java, in order to test that running an external Process is not what's "capturing" and "holding on" to the Ctrl-C signal until GLI exits.

GLI code is approximately at revision 31733.