Add SpectralColor type

[coreh]

Note: This PR has been extracted from #14822

---

Objective

• Add a special type for representing and working with spectral colors (composed of single wavelength light)

Solution

• Introduces a new SpectralColor type, along with a CIE 1931 lookup table for 2-deg XYZ color matching function for conversion to tristimulus color spaces

Testing

• Did you test these changes? If so, how? Yes, unit tests
• Are there any parts that need more testing? Not that I know of
• How can other people (reviewers) test your changes? Is there anything specific they need to know? They can use the snippet below to play with it
• If relevant, what platforms did you test these changes on, and are there any important ones you can't test? macOS

use bevy_color::{SpectralColor, LinearRgba};

fn main() {
    let mut wavelength = 360.0;
    while wavelength <= 830.0 {
        let spectral = SpectralColor::wavelength(wavelength);
        let rgb = LinearRgba::from(spectral);
        println!(
            "{:>5.0} nm -> rgb({:.3}, {:.3}, {:.3})",
            wavelength, rgb.red, rgb.green, rgb.blue
        );
        wavelength += 1.0;
    }
}

[amtep]

Hope you don't mind that I reviewed a draft :) I have some doc fixes and one question.

[amtep]

I checked, and for rows 43 to 57 this generates a linear color with the red value above 1.0, with a max of 2.5166698. Is that okay? LinearRgba says [0.0, 1.0] in its docs for the fields.

[coreh]

I think so? Internally the shaders support and heavily use colors above 1 for highlights, etc, and for things like highlights, emissive, etc. Might be more of a convention than a strict rule? The conversion of LinearRgba to u8 channel values clamps it to 0..=255 per channel, which might be the one real downside here as hue can shift.

Some examples currently use use values > 1.0 directly, so this would not be introducing anything unusual:

bevy/examples/3d/bloom_3d.rs

Line 43 in 01cc975

emissive: LinearRgba::rgb(1000.0, 1000.0, 1000.0),

[altunenes]

as a fan of spec colors just looking through the lookup table interpolation here... wouldn't it be a bit cleaner to avoid the floating point modulo (%) and redundant math by leveraging .fract()? I use the same CIE 1931 table in a WGSL shader and ended up with this form (an experiment): 🙂
https://github.com/altunenes/cuneus/blob/main/examples/shaders/buddhabrot.wgsl

[coreh]

Hmm yeah. I ended up using .floor(), storing an intermediate result and dropping the extra operation entirely.

There's also apparently a closed formula approximation (without lookup table) that @valaphee had mentioned on the original PR, but the link is now gone.