[wpilibc] Fix HSV to RGB conversion off-by-one error (#8722)

`Color::FromHSV` didn't match the Java `Color.fromHSV` in some saturated
edge cases, introducing an off-by-one error when the HSV color should
correspond complete saturation of one or two of the primary colors.

Example:

- Java: `Color.fromHSV(0, 255, 255) -> (255, 0, 0)`
- C++: `Color::FromHSV(0, 255, 255) -> (255, 1, 1)`

This also means the following methods are also transitively affected:

- `AddressableLED::LEDData::SetHSV`
- `LEDPattern::Rainbow`

This off-by-one error is introduced by a rounding error from the chroma
calculation, which was dividing by 256 rather than the appropriate
maximum value of 255 like in Java:


7ca35e5678/wpilibj/src/main/java/edu/wpi/first/wpilibj/util/Color.java (L176-L177)

Also port appropriate tests from Java to C++ to catch this bug.

I found this bug when I tried to port `AddressableLEDBuffer` to RobotPy.
Codex found the root cause :)

wpiutil/src/main/native/include/wpi/util/Color.hpp

@@ -865,7 +865,7 @@ class Color {
     // that changes (X) from low to high (X+m) or high to low (v-X)
 
     // Difference between highest and lowest value of any rgb component
-    int chroma = (s * v) >> 8;
+    int chroma = (s * v) / 255;
 
     // Because hue is 0-180 rather than 0-360 use 30 not 60
     int region = (h / 30) % 6;