Fix some issues with six dependency

[jmoldow]

Add a fallback for six.raise_from, which isn't available in
six 1.4.0. It isn't available until six 1.9.0. We could also
have raised the lower bound for the six requirement, but this is
an easy way to allow clients to keep using their existing
versions of six.

Fix support for the latest version of six, 1.11.0. That release
changed the temporary metaclass returned from
with_metaclass(), such that it directly inherits from type,
instead of inheriting from the target metaclass [1]. We depended
on this detail, and the change caused

.. code-block:: python

TypeError('metaclass conflict: ...')

to be raised when defining a class with with_metaclass(). We
fix this by manually selecting the most derived metaclass, and
including it in our temporary metaclass.

Also, __prepare__ is now defined on the temporary metaclass,
in six 1.11.0 [2]. This allows us to skip our own definition of that
method, when using six>=1.11.0.

Fixes #228.

Fixes #239.

[1] benjaminp/six#191
[2] benjaminp/six#178

[boxcla]

Verified that @jmoldow has signed the CLA. Thanks for the pull request!

[Jeff-Meadows]

If we're going to reimplement raise_from in case it's not defined in the currently installed version of six, shouldn't we define it correctly (ie using the raise from syntax if we're in PY3)?

[jmoldow]

@Jeff-Meadows I didn't want to simply redefine it, because then we'd have code that is identical to what appears in six, and I don't want to get into any licensing grey areas.

I think the way it is is okay. In Python 2, there is no difference. In Python 3, the only difference is the __cause__ attribute, which very few clients will look at. Practically, it only really matters for stacktraces.

My personal preference would be:

1. Keep as-is, or bump the minimum required version of six.
2. Remove use of raise_from.
3. Fully redefine raise_from to match six.

I'd be okay with not using raise_from, since it's more of a nice optimization, rather than something that we must do.

But since six 1.9.0 is over two years old, and since we're doing a major version bump, I guess I'd be fine changing this to increase the minimum version, if we don't want to do weird things like redefine a partially-implemented raise_from.

[Jeff-Meadows]

@jmoldow I'd rather not reimplement than partially reimplement. I think bumping the minimum to 1.9.0 is perfectly fine (I'd also be fine bumping to 1.11.0 in the 2.0 branch and removing the additional with_metaclass code)

[jmoldow]

Bumped the minimum to 1.9.0.

[Jeff-Meadows]

Can you also bump the requirement in requirements.txt?

[jmoldow]

I removed the entries from requirements.txt, since I don't believe there is anything gained from duplicating everything.