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.
That seems like a good idea... alternatively, what would you think about the slot itself having a "wrap a block" method we could call on it? Then both those cases could just be `slot.wrap_block(blk)` and leave the business near `Slot#eval_block`.