[hal, wpilib] AddressableLED: allow selecting color order

[rzblue]

Supercedes #2329

Many LED strips use different color order (GRB in particular is common).

Unlike #2329, this makes the change at the HAL level. This solves 2 problems; first, no code needs to change in the high level drivers, which was challenging for C++, and second, simulation will behave properly as no conversion is needed. The HAL will accept an array of data objects in the same order no matter what the selected output order is, and will convert before sending it to the FPGA for output.

To accomplish this, NEON bulk load/interleave instructions are utilized. The low level implementation (load, store, and alignment functions) come from the Simd Library. The high level implementations are inspired by the image conversion functions in the simd library, but have diverged significantly.

Much of the implementation uses templates and inlined functions rather than runtime parameters; This is a trade off between the size of the generated code and the amount of function calls done at runtime. Currently, the entire conversion operation is inlined.

Opening this as a draft for organizational feedback, there's some cleanup and simplification I want to do still.

• Test small string implementation
• Java high level implementation
• Test on hardware (make sure the actual output bitstream matches the selected order)

[calcmogul]

Can this code be leveraged to eliminate more of our OpenCV-dependent code? One of the only reasons we use OpenCV is colorspace conversion.

[PeterJohnson]

Using the SIMD library to replace the cscore use of OpenCV is something that has been on my project idea board for a while. The SIMD library has more general purpose functions for graphics.