WIP: add top-level eval function

closes #3393.

This is a ways from being mergeable but I thought I would put up the PR for people to play with and to get some other eyes on it. Tire-kick at will. A consolidated list of things to be completed to come.

`eval` Roadmap
======

Documentation
---
- [ ] enhancing performance section
- [x] `eval` docstring
- [ ] Warn users that this is *not* a magic bullet

  * E.g., `x = 3; y = 2; pd.eval('x // y', engine='python')` is 1000 times slower than the same operation in actual Python.

Engines
-------
- [x] python engine for testing (basically a restricted eval, should make sure nothing dangerous a la `eval('os.system("sudo rm -rf /")')`) is possible here
- [x] numexpr engine
- [x] pytables engine (#4155)

Should python be the default engine for small frames?

Functions
------
- [x] toplevel `isexpr`
- [x] move `eval` to top-level pandas

Error Handling
-------
- [x] syntax error handling
- [x] name error handling

Alignment
------
* Algorithm
  1. flatten the tree of terms
  2. resolve the variables, special casing only numpy arrays/scalars/single unary operations (probably room for more  abstraction here)
  3. align by joining on the indices using the current broadcasting behavior
  5. update the original namespace with the newly aligned version of the underlying numpy array
  4. reconstruct the final object with the aforementioned joined indices and type

- [ ] punt to `'python'` engine when a `Series` and `DataFrame` both have `DatetimeIndexes` (I would rather not do this and just enforce the to-be-deprecated index-aligning-if-both-indices-are-datetimeindex behavior)
- [ ] `PeriodIndex`es don't work (well, they won't pass my tests) because of a stack overflow bug when joining a `DatetimeIndex` and a `PeriodIndex` (that bug is slated for 0.13, but a design decision needs to be made)
- [ ] alignment for `NDFrame` (is this really necessary?)
- [x] unary alignment
- [x] binary alignment

Scope
-----
- [x] deal with global scoping issues (not sure if this is tested well enough...which means probably not)
- [x] allow `Expr` objects to be passed to `eval` (`Expr` will pull in the local and global variables from the calling stack frame)

Miscellaneous
-----
- [ ] replace current `evaluate` function
- [ ] `Expr` in `NDFrame.__getitem__` cc @jreback
- [x] reconstruct the final object to return the expected output type, e.g., `df + df2` should return a `DataFrame` if `df` and `df2` are both `DataFrame` objects.
- [x] change `Expression` to `Expr`
- [x] add `truediv` keyword to `Expr`, default to `True`

Operators
------
- [x] `%`
- [x] `**`
- [x] unary ops don't play well when they are operands of binary ops

Tests
-----
- [ ] `DatetimeIndex` and `PeriodIndex` objects are untested because of a few join and alignment issues.
- [ ] rewrite a few tests in the python evaluator to make sure the `//` operator works as it should (it works, but there may be edge cases that I haven't though of yet)
- [ ] `//` `numexpr` only supports scalar evaluation here: variables are not allowed so this will always eval in python space (half-assed it a bit in the tests here need to fix that)
- [x] truediv keyword tests
- [x] add tests for nans
- [x] fix `**` associativity issue in testing

Near Future
------
- allow `and`, `or` and `not` aliases for the operators `&`, `|` and `~`, respectively
- attribute accessing e.g., `df.A` syntax
- reductions (`sum` and `prod`)
- math ops (sin, cos, tan, sqrt, etc.)

Far Future
------
- non-python indexing (or just punt to python)