Added styling and clicking to buttons

Hi all,

The goal was to get Button to use `style_with` and `style_init` (see #711) which was a daunting task since that meant changing the SWT side of how button works (see [this comment](https://github.com/shoes/shoes4/pull/768#issuecomment-46875574)).

`button` `radio` `check` and `link` are all very related, especially in the backend. So in order to get this to work I had to work on all 4 at the same time (thankfully, I didn't have to do too much with link).

The good news is it works! And it passes specs (well on the surface, I'll get into that in the inline comments). It also resolves #748.

The bad news is, it's A LOT to change in one gulp, and even though it passes the standing specs, I still need to write the specs that *weren't* failing.

Unfortunately I won't be able to write the inline comments for another couple hours or so. So if you're eager feel free to dig in and play around (or at the very least write some clicky apps). Otherwise I'll give more details soon enough. 

:confetti_ball: 
This actually *almost* makes sense to me, because of the order that we're defining the methods in our `Shoes::Arc` class (and most others). The pertinent bits are that we:

  * `include Common::UIElement` (which in turn includes the `DimensionsDelegations` where `left` is supposed to come from)
  * then we call `style_with` which without the check to not touch existing methods will override what we got from `DimensionsDelegations`

That's actually the exact opposite of the order we want. Maybe if we were to change the ordering and do this, it might work:

```
include Common::Style
style_with ....

include Common::UIElement
...
```

But then I'm not entirely positive whether `Common::Style` and `style_with` would have all the supporting stuff they might need. (i.e. do the style defining methods rely on anything out of `Common::UIElement` that wouldn't be there if you swapped the ordering).

I'll also call out that having this be so dependent on order seems like potentially a bad idea. While reordering modules isn't *always* safe, it is often enough that it might be a surprise if making that change broke things badly to some future programmer.