SPARK-2257: Make execution on Event Dispatch Thread more explicit
Swing event handling code runs on a special thread known as the event dispatch thread. Most code that invokes Swing methods also runs on this thread. This is necessary because most Swing object methods are not "thread safe": invoking them from multiple threads risks thread interference or memory consistency errors. Some Swing component methods are labelled "thread safe" in the API specification; these can be safely invoked from any thread. All other Swing component methods must be invoked from the event dispatch thread. Programs that ignore this rule may function correctly most of the time, but are subject to unpredictable errors that are difficult to reproduce.
It's useful to think of the code running on the event dispatch thread as a series of short tasks. Most tasks are invocations of event-handling methods, such as ActionListener.actionPerformed. Other tasks can be scheduled by application code, using invokeLater or invokeAndWait. Tasks on the event dispatch thread must finish quickly; if they don't, unhandled events back up and the user interface becomes unresponsive.
Spark should make clear what code is, and what code is not supposed to be executed on the Event Dispatch thread. This will help reduce instances where the UI seems frozen for prolonged periods of time, or otherwise behaves in an unexpected manner.
This commit adds comments to various methods (particularly around the login sequence) that define if the method is to be executed on the Event Dispatch Thread. Also, when ran in debug mode, code-checks will fail-fast, if such methods are executed differently. This will help spot problems.
