ENH: add expression evaluation functionality via eval

closes #3393
closes #2560 

cc @jreback

`eval` Roadmap
======

PyTables
----
allows natural syntax for queries, with in-line variables allowed

some examples
``"ts>=Timestamp('2012-02-01') & users=['a','b','c']"``

``['A > 0']``

``'(index>df.index[3] & index<=df.index[6]) | string="bar"'``

```
dates=pd.date_range('20130101',periods=5)
'index>dates'
```
Todos:

- [x] Release Notes
- [x] v0.13.txt examples (and link to docs)
- [x] update docs / need new examples
- [x] API changes (disallow dict, show deprecations for separated expressions)
- [x] tests for ``|`` and ``~`` operators
- [x] tests for invalid filter expressions
- [x] code clean up, maybe create new ``Expr`` base class to opt in/out of allowed operations
      (e.g. ``Numexpr`` doesn't want to allow certain operations, but ``PyTables`` needs them,
       so maybe define in the base class for simplicity, and just not allow them (checked in ``visit``),
       which right now doesn't allow a ``generic_visitor``)
- [x] can ``ops.Value`` be equiv of ``ops.Constant``?

`query` method
-----
- [x] a few more doc examples
- [x] add a section in `query` docstring to show use of `__getitem__` and then add to `indexing.rst`
- [x] `query` docstring

`DataFrame.eval` method
-----
- [x] implement query in terms of this
- [x] tests

Documentation
---
- [x] **RELEASE NOTES**
- [x] v0.13.txt examples & link to docs
- [x] document `in` and `not in`
- [x] enhancing performance section
- [x] `eval` docstring
- [x] Warn users that this is *not* a magic bullet

  * E.g., `x = 3; y = 2; pd.eval('x // y', engine='python')` is many 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

Parsers
------
- [x] `python` parser is currrently not failing on complex bool ops involving subscripting like it should (potentially could `eval` the compiled AST instead of dispatching to function calls)
- [x] preparse should handle subscripting
- [x] `pandas` parser should handle subscripting, i.e., `df.query(...) == pd.eval('df[...]')`
- [x] `pandas` parser
- [x] `python` parser
- [x] `pytables` engine and parser (internal)

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
- [x] ugly stack overflow when an expression is not in frame...issue with variable resolution in `expr.py`. should fail fast.

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


- [x] unary alignment
- [x] binary alignment

Scope
-----
- [x] add `@a` syntax for referencing local variables with the same name as a column
- [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
-----
- [x] support for `MultiIndex` queries
- [x] **remove instance testing methods once series ndframe is merged**
- [x] `str` ops (implemented using `isin`)
- [x] basic `Timestamp` and `datetime` functionality
- [x] vbench!
- [x] single variable or constant evaluation e.g., `pd.eval('1')` or `pd.eval('df')`
- [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`
- [x] allow `and`, `or` and `not` aliases for the operators `&`, `|` and `~`, respectively
- [x] chained comparisons
- [x] attribute access syntax e.g., `df.A`

Operators
------
- [x] `%`
- [x] `**`
- [x] unary ops don't play well when they are operands of binary ops

Tests
-----
- [ ] `PeriodIndex` objects are untested at large (a few scattered tests for basic things)
- [x] add tests for strange column names e.g., `df['@awesome_domain']`, `df['df["$10"]']`
- [x] Python 3 handles complex scalars differently, so test that
- [x] **revert equality testing in `align.py` once #4379 is merged**
- [x] boolean ops fail with a `DataFrame` with a `PeriodIndex` in the columns
- [x] test alignment of `DatetimeIndex` objects
- [x] 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)
- [x] `//` `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

Syntax (Easier)
-----
- [x] handle `in`, `not in` ( ~~was thinking~~ implemented as `a in b` -> `b.isin(a)` and `a not in b` -> `not a in b` -> `~b.isin(a)`)

Syntax (More difficult)
------
- reductions (`sum` and `prod`)
- math ops (sin, cos, tan, sqrt, etc.), i.e., whatever `numexpr` supports
- ~~function calls~~ (we're not building a Python interpreter here :wink:)

Optimizations
------
There's a quite a bit of recursion going on here, where maybe something stack-based might be more efficient. For example, an expression like `df['f in g and a < b < (c ** 2 + b ** 2 - a ** 3) and d in b not in e']` will make 3 recursive calls to eval (not including the top level call). One for the first `in` expression and two for the `in`/`not in` chain. A stack-based implementation of the parser (instead of recursively visiting nodes) could possible shave off a few milliseconds. Not sure if this is worth it though.

Others
----
- ~~alignment for `NDFrame`~~ #4336 
- ~~replace current `evaluate` function~~