Make columnwise lambda debuggable

Instead of `eval`-ing a `lambda` string, this PR introduces a `Lambda` class whose `__call__` method takes the row being computed over. The expression to be computed is given in the constructor, like so:

```python
from blaze.expr import Lambda, TableSymbol
from datetime import datetime
t = TableSymbol('t', '{id: int, datetime: datetime}')
expr = t.datetime == datetime(2000, 1, 1, 1, 1, 1)
f = Lambda(expr.expr, t.columns)
```

In IPython

```
In [12]: from blaze.expr import Lambda, TableSymbol

In [13]: from datetime import datetime

In [14]: t = TableSymbol('t', '{id: int, datetime: datetime}')

In [15]: expr = t.datetime == datetime(2000, 1, 1, 1, 1, 1)

In [16]: f = Lambda(expr.expr, t.columns)

In [17]: f
Out[17]: lambda id, datetime: datetime == ('2000-01-01 01:01:01')
```
Well, we often do dispatch on scalar expressions, particularly within the numpy, pandas, and sqlalchemy backends.  I guess I wouldn't use the term parser here, rather we interpret/lower blaze expressions onto another representation.

In the case of Python functions the two approaches that come to my mind are 

1.  Something like the str/eval trick that is in master now
2.  Build up a function using standard Python functions like closures and compositions, this is similar to rowfunc in compute/python.py

What is currently in this branch feels like a combination of the two.  Seeing `parse(str(expr))` raises some complexity warning bells for me. So too does walking a tree for every row for performance reasons.

While I appreciate the ugliness of `eval(str(expr))` (full of warning bells itself) it does appear to be fairly efficient and decently simple.  It's a low-sophistication approach that performs decently.  My opinion anyway.