Fix problems with the Python extension module build:
- Explicitly build against downloaded NumPy headers instead of relying on the build OS implicitly via the compiler's built-in paths, fixing #1283.
- Use tagged, verified downloads of pybind11_bazel and pybind to silence noise in the bazel output and improve tamper resistance, reproducibility, and caching.
The underlying issue was that the extension module depends on header files from numpy but that dependency was not captured in the BUILD rules.
Upstream Tensorflow's solution is too complicated to import. They manage dependencies on Python runtimes and libraries via much more extensive system of [custom rules](https://github.com/tensorflow/tensorflow/tree/master/third_party/py), designed to meet their many additional requirements.
Background:
- [pybind/pybind11](https://github.com/pybind/pybind11) is a C++ library that helps in creating our extension's interface to CPython.
- [pybind/pybind11_bazel](https://github.com/pybind/pybind11_bazel) provides Bazel rules for building pybind-based extensions, but doesn't cover the unusual case of using C headers provided in another Python module (in our case, NumPy).
- Bazel's own [bazelbuild/rules_python](https://github.com/bazelbuild/rules_python) provides rules for fetching Python dependencies from PyPI for use when *running* Python code via Bazel, but doesn't directly help with the unusual case of *building* code using headers provided by Python packages from PyPI (again, in our case, NumPy).
- The standard way, in Bazel, to build against third-party code is to create an [external repository](https://bazel.build/docs/external) by writing and calling [repository rules](https://bazel.build/extending/repo).
This PR supplies the C headers from NumPy to the build of our extension by adding a repository (via the new repository rule `tflm_py_cc_headers`) that reuses the PyPI package downloaded by rules_python and wraps it in a `cc_library` target on which the build of the extension can depend.
BUG=fixes #1283
