support X-Trans sensor raw files

X-Trans specific changes:

- use RawSpeed to read RAF files
- downsampling for fast display
- interpolation: bilinear, VNG, and modified AHD (aka Markesteijn), all adapted from dcraw; these operate on floats and use OpenMP
- highlights, hotpixels, invert, rawdenoise, temperature handle X-Trans
- disable cacorrect for X-Trans
- white balance presets and basecurve for X100S
- cameras.xml and adobe_coeff.c entries X-Series cameras
- documentation updates
- dngmeta.sh handles X-Trans

None of these changes should alter performance for users of Bayer sensors. The changes have been tested on Bayer and X-Trans matrix raws as well LDR files.

The code in this pull request doesn't:

- handle "dynamic range" feature on X-Series cameras
- implement SSE/OpenCL optimizations
- implement cacorrect for X-Trans sensors
- include white balance data and basecurves for X-Series cameras besides X100S

There is generally one commit for each major change. For the VNG/Markesteijn demosaic code, one commit imports/wraps code from dcraw, then another modifies this code to use floats/OpenMP and otherwise make it more specific to darktable.

This pull request closes #9951 and fixes #9388.

If it becomes necessary to update to the latest LibRaw, see separate branch libraw-0.16 (https://github.com/dtorop/darktable/tree/libraw-0.16). This pull request for the "xtrans2" branch keeps the extant LibRaw 0.14.7 (with the addition of a small patch to not break the temperature iop for the X-Pro1) so as not to add another LibRaw dependency.
From some quick profiling on a Core i7, speed appears limited by memory access, and the modulo isn't a bottleneck. I can't figure out how to make a power of 2 sized array work with the modulo 6 CFA (either padded or by repeating each rows/cols). Is it a mathematical impossibility or am I being dense? Any advice most welcome.

There are also some fast modulo 6 divisions (based on a fast modulo 3 http://homepage.cs.uiowa.edu/~jones/bcd/mod.shtml, https://stackoverflow.com/questions/1697358/fast-modulo-3-or-division-algorithm, http://compilers.iecc.com/comparch/article/99-10-056). Knowing that row & column will not be that large also helps, and this would also make things nicer with the negative row/col values which happen in demosaicing. But is this worth the obscure code if it isn't really a bottleneck -- and the compiler and CPU architecture are already doing a good job?

Regardless, as the CFA data is loaded into dt_image_t every time an image is read, and not stored in sidecar files or such, it should be possible to implement a changed format for it later if that becomes necessary.