Basic proof-of-concept for clean execution context

This is a quick and dirty experiment with one way of providing a clean execution environment for user app code. It only works with very simple apps, like the one below, or `sample1.rb`, or `sample2.rb`. It breaks *TONS* of specs, because I haven't taken it all the way through the Slot code, etc.

Here again is the app from #492 (modified so the "gui" button displays some output):

```ruby
def width
  "EXTRA WIDE"
end

def breadth
  "EXTRA BROAD"
end

Shoes.app do
  button "breadth" do
    title "Breadth: #{breadth}" # Breadth: EXTRA BROAD
  end

  button "width" do
    title "Width: #{width}"     # Width: EXTRA WIDE
  end

  button "gui" do
    @gui = "EXTRA GUI"
    title "Gui: #{@gui}"         # EXTRA GUI
  end
end
```

**using the master branch:**

![screen shot 2013-12-14 at 11 48 48 pm](https://f.cloud.github.com/assets/908/1749877/b59c4978-654c-11e3-8b11-75759b452d7a.png)

(When you click "gui", it crashes with `NoMethodError: undefined method `real' for "EXTRA GUI":String`)


**using the context branch, with `Shoes::Context`:**

![screen shot 2013-12-14 at 11 28 50 pm](https://f.cloud.github.com/assets/908/1749873/1c61fa0a-654c-11e3-9b51-3850f86c6ef3.png)

So this gives us as clean of an execution context as I think we can expect. There is only one instance variable in addition to the DSL methods. I think that, using this approach, we could go so far as to make `Shoes::DSL` a class instead of a module, give an app an instance of that class, and have the `Shoes::DSL` instance be the execution context.

Another option would be to turn this one inside out and have the `Shoes::App` itself be the execution context, pushing all of its state into something like `@__privates__`.

What do you all think???

this pull request addresses #492 and #82