`.future` returns a `Future` object (either a native `asyncio` `Future`,
or a Tornado `Future`), which can be `yield`-ed (Tornado on Python <3.4)
or `await`-ed (Python 3.5+).

…hon.

Python older than v3.3 does not understand `yield from`, and won't
ignore it inspite of it being in a code path that won't be run for older
releases.

So instead, we have to put it in a completely separate file and convince
Python to hopefully not import it when running on older Python releases.

There are some "extra" features, which are not required for `pyhaystack`
to run, but may make its use more pleasant.

- `pandas`: Installing this drags in a _lot_ of X11-related dependencies
  on Linux-based platforms, so it makes sense to make this "optional"
  for "embedded" use cases where advanced computation is not being
  performed.
- `tornado`: Support for the Tornado IO loop.  Mostly this only matters
  for Python 2.7 users who may still want to drive `pyhaystack`
  asynchronously.

Some of these branches are impossible to test since unless Shrödinger
starts writing Python packages, we can't have a package simultaneously
"installed" and "uninstalled" at the same time.

…from coverage.

…low copy.

This allows for objects to be shallow-copied using `__copy__`, instead
of relying on the object having a `.copy` method.

…class.

…tation

With wrapper to "hide" the tests from Python < 3.5.

`extras_require` should be a `dict` not a `list`, Duh!

… hide from Python 2.

At the moment, installing `pyhaystack` on Python 2 works, but it throws
an error (which it then ignores) when it tries to "compile" the `.py`
file to `.pyo`.

Since these files have no use in a Python 2 install, let's move them
into a sub-package which we can selectively import if and only if Python
3 is in use.