Proof concept: message passing

Moving to a design where I pass custom messages rather than swing Events. This way the view maps buttons/textfields to messages rather than the model or operationObj. I could push this farther and have the operation send a message too, but I think that could push me a bit far into the 'reinventing methods via enums' territory.

I'll meditate a bit more on the two way messaging in a moment. Otherwise, I need to pull out the previous way of doing that, as RunClock is still generating all the objects. That needs to be pushed up into Run or the ViewRoot.
More messages, real control

Message passing now works in both directions. My earlier commit was a bit premature given that it still relied on swing event passing. I should look at the mediator pattern again to make sure I'm not missing a useful piece. Here, I put more enums, renamed to begin with flag_ .

The SettingsChanger also has spinners for the ClockView.frame x & y positions. This changes them at runtime by the magic of listening for ChangeEvents. So, while there's a bit of work in stringing up similar spinners for most of the other fields, the template is there to draw from now.

Renamed some other classes so they group nicely. Removed EventInt given it's not listening anymore. May refer to it in the future.