Lazy evaluation

Based on #580.

* http://en.wikipedia.org/wiki/Lazy_future#Promise_pipelining

For example:

```python
        with context.lazy_eval():
            a = context.zeros((52, 62))
            b = context.ones((52, 62))
            c = context.ones((52, 62)) + 1
            d = (2*a + (3*b + 4*c)) / 2
            e = globalapi.negative(d * d)
```

Our implementation
--------------------------
On the client, when `<context>.lazy == True`:
* Sends are intercepted and queued (in `<context>._sendq`)
* Recvs return immediately, queueing a lazy placeholder object inside a returned proxy object
* When `<context>.sync()` is called, the both queues are sent to the engines (one queue per engine actually), and a real `recv` is blocked upon.

On the engines, when a `'process_message_queue'` message is received (containing the queues):
* Each message in the `sendq` is processed, one at a time, and the placeholder values from the `recvq` are used to feed values forward into the engine-side computation
* Client-sends (return values) are queued, and sent as one message once the queue is processed.

On the client:
* The client iterates through this return queue, and the lazy placeholders inside the originally reserved proxies are replaced by the real return values.

A note on my names
----------------------------
There's a `Context` attribute called `lazy`, and a `Context` method called `lazy_eval()` that is a context manager (decorated by `contextlib.contextmanager`) that sets and unsets `lazy` under the hood.  If you have better ideas for those names, let me know.

Benchmark
---------------
I also added a simple benchmark in `examples/lazy_eval`.  I time a loop that computes `tanh` on a DistArray for a settable number of iterations, both in lazy mode or in the default eager mode.  Lazy mode seems to beat eager, but it's not as dramatic as I would have expected.  I should probably think through the benchmark more.
There isn't time to implement it, but it feels like `nresults` should be an attribute on the local function somehow, either with a decorator or a function annotation for the return value or something.  Perhaps we can write it up in an issue...