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 imagine a basic `return false if hidden?` as a guard statement on top, granted that would have to be repeated in all overrides... we could use a template method... worried about naming/pending

```ruby
def in_bounds?(*args)
  return false if hidden?
  contains_point?(args) # internal implementation when concrete handling should be overridden, also comes with our good old base implementation in Dimensions
end
```