Switch to app-level click listener

Couldn't resist after realizing what was happening on #882. Here's my shot at fixing the problem with events getting delivered when we didn't want them (specifically in that case, elements that were created in other click handlers).

The basic course I took was based on realizing we didn't need every element creating its own SWT-level listener. Instead, the window has one listener, and we do the element selection and dispatch ourselves. This gives us final control over who receives the event (in this case the final subscriber that's in bounds... maybe later we can get smarter like Shoes 3 where the top-most visible element gets it).

This deserves more testing, but some basics and links (which were the more complicated case for click support) are all working from what I've checked tonight (and specs were passing too).

:mouse: :white_check_mark: :boom: 

Things to check
* [ ] Run through samples, especially any that have click behavior
* [ ] See if we can get rid of any further oddities around how links set up their clicks now that things are simpler
* [ ] Should the shared `"swt app"` context have a `click_listener` set up automatically? Had several spots where I popped in a do-nothing version for tests to run.
Yeah, you're exactly right--it's my stand-in for having an actual z-index.

The change in hash ordering you're thinking of is that hashes in 1.8.x Ruby were unordered, and 1.9 changed that to keep them ordered. So this will do what I was intending--the last element added to the app that responds to the click gets its shot.

This is obviously not perfect in the case of dynamic elements, dynamic click/release registering, all sorts of things, but this seems valuable enough even without resolving that.