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.
I was thinking about letting `in_bounds?` return false if an element is hidden (as nothing can be in bounds atm), need to check shoes3 behavior and maybe open an issue. Is it even a shoes3 method? I probably invented it...

If we don't want that behavior I'd be for adding another method that does this, as it's a common behavior I want to have