Incorporate explicit-SIMD branch into master

[skyreflectedinmirrors]

This MR incorporates the work I have been doing on enabling explicit-SIMD vectorization into master, in one of the final pushes before the first beta release. In addition to enabling explicit-SIMD dtypes for wide-OpenCL vectorizations, this also:

1. Completely re-writes the kernel / wrapper generator using the Cog templating package. This makes generation of the kernels (and in particularly, the wrapping code that calls the kernels) much more flexible as compared to the previous string-template based method. This will be useful for incorporating more targets (e.g., OpenMP-vec, ISPC, CUDA, etc.). In addition, the wrapper is now C++ based, allowing for overrides such that we can place multiple kernel definitions in the same library (though currently we have just one per library), de-duplicates constants between the various core-kernel files, and handles array initialization automatically (based on # of threads / GPU blocks & problem size)

2. Adopts a copy-in / copy-out driver-based method to evaluated the kernels of the set of initial conditions. This has the important side effects of a) greatly reducing spyJac's memory footprint (as we only need small working buffers for each thread / GPU block, rather than each initial condition) and b) makes calling the core-kernel functions from outside codes much easier, as the interior kernels now operate on local copies of the arrays, i.e., you can do stack based calls:

double rwk[1024];
double phi[53];
double dphi[53];
double P = 101325;
// populate arrays
// ...
// ...
species_rates(0, &P, phi, dphi, rwk);

The final remaining issues before we're ready to fully advertise beta-release are:

• documentation (#16)
• adding info to kernel objects (#14)
• I'm still waiting on finalizing some of my additions to loo.py (this commit switches the required loo.py package to my own working branch)

Things that would be nice to have, but aren't 100% critical:

• Possibly adding a Cog-generated make-file based build system such that it is easier to build the interior kernels into a library separately from the wrapping code
• Fix naming conventions / other flake errors

@kahilah @kyleniemeyer

[kyleniemeyer]

I noticed some commits that mention Python 2.x compatibility—not sure that's important, since everything else is dropping it.

[skyreflectedinmirrors]

@kyleniemeyer I know that Cantera is in the process of dropping 2.7 support, but it is it wider spread than that? Regardless once Cantera drops 2.7 support, we will likely be forced to as well (as we can't run the unit-tests w/o CT)

[kyleniemeyer]

Yes, the whole scientific Python world is dropping 2.x support. Starting January 1 2019, NumPy is only releasing new features for Python 3, and completely dropping 2.7 one year later: https://docs.scipy.org/doc/numpy-1.14.0/neps/dropping-python2.7-proposal.html

In fact, Matplotlib 3.0 (just released) already stopped Python 2 support, it's Python 3 only!

So yeah, I don't think we should be particularly concerned about supporting Python 2.x, and it might be better to explicitly remove it.

[skyreflectedinmirrors]

Gotcha, it seems like pre-beta is as good a time as any officially to drop 2.x support.

[skyreflectedinmirrors]

All passed except flake!