Define a prelude for bevy_color, and add it to bevy_internal

[alice-i-cecile]

Objective

As we start to migrate to bevy_color in earnest (#12056), we should make it visible to Bevy users, and usable in examples.

Solution

1. Add a prelude to bevy_color: I've only excluded the rarely used ColorRange type and the testing-focused color distance module. I definitely think that some color spaces are less useful than others to end users, but at the same time the types used there are very unlikely to conflict with user-facing types.
2. Add bevy_color to bevy_internal as an optional crate.
3. Re-export bevy_color's prelude as part of bevy::prelude.

[AxiomaticSemantics]

There should be entries in the root workspace Cargo.toml or is this meant as a follow-up.

[alice-i-cecile]

There should be entries in the root workspace Cargo.toml or is this meant as a follow-up.

Good catch! Added; please take a look to verify that I did this correctly.

[AxiomaticSemantics]

bevy_render = ["bevy_internal/bevy_render", "bevy_color"]

[github-actions]

You added a new feature but didn't update the readme. Please run cargo run -p build-templated-pages -- update features to update it, and commit the file change.

[AxiomaticSemantics]

I'm thinking even more enabling on features in the root, such as bevy_ui and bevy_sprite possibly.

[github-actions]

You added a new feature but didn't update the readme. Please run cargo run -p build-templated-pages -- update features to update it, and commit the file change.

[alice-i-cecile]

I'm thinking even more enabling on features in the root, such as bevy_ui and bevy_sprite possibly.

I think this is it :) Technically it was already enabled transitively via bevy_render, but this is more explicit and will be more robust to refactors.