dev-python/flask-cors-1.9.0: Bump to 1.9.0

Which was just released on Saturday [1] and fixes some tests on Python
3.4 [2] and improves coverage [3] among other thing.

[1]: https://github.com/wcdolphin/flask-cors/pull/77
[2]: https://github.com/wcdolphin/flask-cors/pull/74
[3]: https://github.com/wcdolphin/flask-cors/pull/75

dev-python/flask-cors-1.8.1: Bump to 1.8.1

Which was just released [1] and now bundles tests/ [2].

[1]: https://github.com/wcdolphin/flask-cors/pull/72
[2]: https://github.com/wcdolphin/flask-cors/pull/71

dev-python/flask-cors: Use best_version instead of equery

To find the location of the installed python-docs.  Zero_Chaos suggested
the best_version approach on #gentoo-python just now.

The installed version of these docs may soon change, with the
python-docs package shifting to a per-slot naming scheme that more
closely matches the upstream Python naming scheme [1].

[1]: https://bugs.gentoo.org/show_bug.cgi?id=522794

Thanks-to: Rick Farina (Zero_Chaos) <zerochaos@gentoo.org>

dev-python/flask-cors: Only depend on the python-docs:2.7

PEP 430 says that links to Python docs without an explicit version are
implicitly requesting the latest 2.x release [1].

[1]: http://legacy.python.org/dev/peps/pep-0430/#don-t-break-useful-resources

dev-python/flask-cors: Drop ROOT and use stricter python-docs dependencies

We're not supposed to use ROOT in ebuild functions (see the discussion
in f3893ec9, dev-python/flask-cors/flask-cors-9999.ebuild: Use local
intersphinx, 2014-09-02).  I had been using it to build against the
objects.inv from that ROOT, but we're actually supposed to build
against the local (non-ROOT) copy [1]:

  ROOT isn't used for library dependencies. When building, libraries,
  headers etc. on / have to be used. Cross-compiling etc is done by
  configuring the toolchain correctly, not by hacking ebuilds in a way
  that breaks binary packages.

I'm also using equery to list the python-docs files (on /), to avoid
hard-coding /usr/share/doc"/python-docs-*/html.  equery knows what was
installed, and I really don't care where it is, so long as I can find
the objects.inv (and so long as that's the directory with the HTML
docs too).

Finally, the python-docs dependencies make sure we accept any of the
python-docs versions that install objects.inv [2].  Ian Delaney bumped
versions to -r1 so we could determine if objects.inv was installed,
and Ian Stakenvicius pointed out the slotted approach to the disjoint
dependency.

[1]: https://bugs.gentoo.org/show_bug.cgi?id=258125#c0
[2]: https://bugs.gentoo.org/show_bug.cgi?id=521768

Thanks-to: Ian Delaney <idella4@gentoo.org>
Thanks-to: Ian Stakenvicius <axs@gentoo.org>

dev-python/flask-cors/flask-cors-9999.ebuild: Use local intersphinx

Gentoo's python-docs recently learned how to install objects.inv (with
the 2.7.6, 3.3.5, and 3.4.0 ebuilds, but without a revbump [1]).
Avoid the troublesome web access [2,3]:

  loading intersphinx inventory from http://docs.python.org/objects.inv...

Unfortunately, the approach to locating the local objects.inv is a bit
awkward.  Ideally there would be some sort of pkg-config approach to
listing a package's HTML doc directory :p, but until then the best I
can do is shell out to ls with an EROOT-based glob.  Using ROOT in
ebuild functions is illegal though [4] (and by extension, using it via
EROOT may be illegal as well).  Even if it was legal, you're going to
run into trouble if the python-docs dependency was installed with a
different ROOT, which is why I die if PYTHON_DOC is empty.

[1]: https://bugs.gentoo.org/show_bug.cgi?id=521768
     Summary: dev-python/python-docs-3.4.0 doesn't install objects.inv
       for intersphinx
[2]: https://bugs.gentoo.org/show_bug.cgi?id=522064
     Summary: should explicitly disallow network access from existing
       ebuild functions
[3]: https://github.com/gentoo/devmanual.gentoo.org/pull/21
     Summary: ebuild-writing/functions: Don't allow network access
[4]: http://devmanual.gentoo.org/ebuild-writing/common-mistakes/#invalid-use-of-root

dev-python/flask-cors: Add this docker-registry dependency