Remove usage of java.awt.Toolkit
Use SWT instead of AWT to set clipboard contents
Working implementation of clipboard using SWT
First stabs at Clickable refactoring

- determination of whether a click is inside moved to the objects
  themselves (#in_bounds?)
- wrote a general Listener class fixing the occasional error
  output (modification fo Java eigenclass) and therefore maybe
  performance issues
- some code still offers some compatibility for mixed GUI/DSL
  objects as Link is a dsl object and everything else is a GUI
  objects... which would have to be fixed (e.g. make an
  SWT Link)
Merge pull request #288 from shoes/fi/mac_persistence_error

Mac Persistence Error
Fix no cursor showing when hovering a clickable element
Refactoring of mouse cursor handling/handling clickable elements

* also added the hidden? accessor which is more idiomatic for
  queries than hidden (e.g. for getting booleans)
* and the accompanying visible?
ln --> click_listener
Forgot to delete. Refer to 6cb9d706cd
Rename sample50.rb to expert-othello-adjusted.rb.
Some specs for Clickable :-)
removed debbugging output in the URL code
removed TODO from code and made it into #292 [ci skip]
Merge branch 'master' of github.com:shoes/shoes4
Merge pull request #290 from PragTob/refactorClickable

Clickable refactoring
added statements to require swt_shoes/spec_helper where missing
Getting rid of singleton class modification in Shoes::App

- also moved window into the app class, as per manual it can only
  be called from there
- removed the whole @owner modification part and just added a to_s
  method to the App, as only apps seem to be able to be parents
  of other apps.
Include the PaintListener interface into the various painters

* gets rid of many __jcreate_meta! in the profile log
* possibly maybe also some anonymous classes.. dunno
* see #289
Remove the repeated creation of anonymous classes through Struct.new

* For now just gave it a name and us that instead, logs are now
  much cleaner and probably performance is also better but I dunno
  fully as I didn't get to write a benchmark yet that really
  emulates our performance problems
* tag issue #289
* there is some serious duplication going on... which is prime
  for removal
Implement Shoes.setup to print a warning message

Shoes 3 Had a way of specifying gems a Shoes app depends on, like so

    Shoes.setup do
      gem 'nokogiri ~>1.6.0'
    end

This was relevant then because Shoes embedded its own Ruby, in this case it
would take care of installing the gem in the right place and loading it in
the app.

In Shoes 4 we will no longer do this, the user can use the standard tools
(gem install, or bundler on top of that) and require the needed files in
the Shoes app.

To ease the upgrade path for people coming from Shoes 3 (or relying on outdated
documentation) we print a warning telling them what to do. This is what it looks
like.

    WARN: The Shoes.setup method is no longer used, you need to install gems yourself.
    WARN: To use the 'bluecloth' gem, install it with 'gem install bluecloth --version "=2.0.6"', and put 'require "bluecloth"' at the top of your Shoes program.
    WARN: To use the 'metaid' gem, install it with 'gem install metaid ', and put 'require "metaid"' at the top of your Shoes program.