Capture slot context for timer and download

Fixes #876 and addresses the `download` problem noted at https://github.com/shoes/shoes4/issues/617#issuecomment-64933275

Both `timer` and `download` take action asynchronously, but can be called from within a nested slot context. For instance, take this test app:

```
Shoes.app do
  stack do
    background blue
    para "Nothing"

    timer 1 do
      para "Something"
    end

    download "http://jasonrclark.com" do |dl|
      body = dl.respond_to?(:read) ? dl.read : dl.response.body
      para body
    end
  end
end
```

Although the `timer` and `download` make it look like their UI will show up within the blue `stack`, we instead get this result:

![image](https://cloud.githubusercontent.com/assets/130504/5258529/ebb70120-79a4-11e4-96ee-4955631ae3a5.png)


This PR captures the context of the `current_slot` with the `timer` and `download` blocks, and wraps them setting that slot context again when they are run. Now we get everything inside the `stack` like you'd expect:

![image](https://cloud.githubusercontent.com/assets/130504/5258538/0c12848a-79a5-11e4-8931-e887ed3436ac.png)


The only other case that I've found with this type of delayed behavior is `animate`, but I'm very leery of changing that since we've established elsewhere that animations don't seem to act in any way like they live within the slot they're called from.
this whole set could go into its own separate method, that deals with the blocks. Also I think `@slot` could be just a local variable (then in that method, or just like this). When I see instance variables, I mostly assume we need the reference/it's an intrinsic property of the object.