Implement initial support for Numba

[polsys]

Part of #25 meta-issue.

I want to trial Numba in production, and hence would like to include it in Alpha 2. The library seems to be not complete/stable enough for the conditional MI code path, but the unconditional MI path works and has significant performance benefits.

• [ ] Implement Numba acceleration for the unconditional MI code path
• [ ] Try to see which parts of the conditional MI code can be JIT-compiled
• [ ] Make the acceleration optional; only enable it if Numba is installed in the current environment
• [ ] Add an extras_require entry for Numba
• [ ] Run the CI both with and without Numba installed (note that coverage is not yet supported)
• [ ] Add instructions for troubleshooting, NUMBA_DISABLE_JIT and using a clean virtual environment
• [ ] Determine the minimum version of Numba to support

[polsys]

Pushed the initial-numba branch with the basic implementation in 129f2de. Still missing: making the integration conditional, documentation, CI.

I still hit several issues with the package:

• The development cycle was basically "typing error -> tweak something -> segfault -> tweak something -> repeat".
• Runtime type errors are no longer TypeErrors but ugly Numba internal errors (or even crashes).
• In general, this seems to be like combining the strictness of Python type system with the memory safety of C. It does not help that Numba implements its own type system parallel to Python's.
• @jitclass does not support the cache parameter yet, leading to recompilation on every run.
• The benchmarks are fast, but the unit tests are much slower.

I am not confident enough in Numba to include the support in 1.0. I think the idea is great, but the implementation is still too unstable. I will be happy to consider it for future releases.

Hence, this issue is now blocked on #40.

[polsys]

Tried another approach based on the above comment; pushed as the basic-numba branch 34a04ea. Now I clearly separated a Numba implementation and "pure Python" implementation. I also took scipy.spatial.cKDTree into use in the latter. Good news is that I got the Numba implementation working pretty well, and it even outperforms the cKDTree approach in some cases. However:

• With small k, the Numba implementation is clearly faster, but by k=10 the SciPy algorithm is better. The same with large n.
• The SciPy data structure is O(sqrt(k) N) while our naive data structure is O(k N). I think we can outperform the SciPy data structure as we don't need full generality, but it wouldn't be so easy.
• The conditional MI (and multidimensional entropy) code path would still need data structure development.
• Numba imposes some extra cost on every process startup, especially as @jitclass does not support caching. It is also a fairly large dependency, it might have platform-specific issues, and it still has breaking changes.

Numba is very promising, but I think it's better not to depend on an alpha-quality package. The maintenance cost would probably become too high. Closing this as the result.