arrow

ARROW-1896: [C++] Do not allocate memory inside CastKernel. Clean up template instantiation to not generate dead identity cast code

Also resolves ARROW-4110, which has been on my list for some time.

This ended up being a huge pain.

* `detail::PrimitiveAllocatingUnaryKernel` can now allocate memory for any kind of fixed width type.
* I factored out simple bitmap propagation into `detail::PropagateNulls`
* I moved the null count resolution code one level down into `ArrayData`, since there are cases where it may be set to `kUnknownNullCount` (e.g. after a slice) and you need to know what it is. This isn't tested but I suggest addressing this in a follow up patch

I also moved hand-maintained macro spaghetti for instantiating CastFunctors into a Python code-generation script. This might be the most controversial change in this patch, but the problem here is that we needed to exclude 1 macro case for each numeric type -- currently they were relying on `NUMERIC_CASES`. This means the list of generated types is slightly different for each type, lending to poor code reuse. Rather than maintaining this code by hand, it is _so much simpler_ to generate it with a script.

Speaking of code generation, I think we should continue to invest in code generation scripts to make generating mundane C++ code for pre-compiled kernels simpler. I checked the file in but I'm not opposed to auto-generating the files as part of the CMake build -- we could do that in a follow up PR.

Author: Wes McKinney <wesm+git@apache.org>

Closes #3642 from wesm/ARROW-1896 and squashes the following commits:

57d10840c <Wes McKinney> Fix another clang warning
0d3a7b39c <Wes McKinney> Fix clang warning on macOS
8aeaf967c <Wes McKinney> Code review
ab534d174 <Wes McKinney> Fix dictionary->dense conversion for Decimal128
7a178a4be <Wes McKinney> Refactoring around kernel memory allocation, do not allocate memory inside CastKernel. Use code generation to avoid instantiating CastFunctors for identity casts that are never used