Color-related convenience methods should be more permissive

[alice-i-cecile]

What problem does this solve or what need does it fill?

When constructing a StandardMaterial or MaterialMesh2d, it's frustrating that only Color can be used.

let material = materials.add(StandardMaterial::from(Color::from(PINK)));

Users will rightly expect that any color type can be used.

What solution would you like?

These Color-specific APIs should be generalized, to accept any type that can be converted into a Color.

What alternative(s) have you considered?

We could use anything that can be converted into a LinearRgba instead. While this is perhaps more conceptually correct, it results in implicitly changing the color space of the provided color, which is a large part of why #12212 was rejected.

Additional context

This was brought up by @superdump and spawned a long discussion on related topics, but everyone seems broadly on board with this as a straightforward improvement.

[NthTensor]

My suggestion was the following. It's kind of gross looking and idk if it will trip up things like rust analyzer.

impl<C: Into<Color>> From<C> for StandardMaterial
    fn from(color: C) -> StandardMaterial {
        StandardMaterial::from(color.into())
    }
}

[cart]

Rust Analyzer would be fine with it. However there is the problem that blanket trait impls block other impls for upstream types:

[NthTensor]

So either a color space trait or a macro then I guess.

[mintlu8]

I suggest be explicit and provide StandardMaterial::from_color.