Support and test compiling with `-Z minimal-versions`

[`-Z minimal-versions`](https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#minimal-versions) is an unstable cargo flag to generate a `Cargo.lock` with the minimal versions possible, rather than the latest ones. This helps finding cases where a crate depends on features of a dependency which were released in a later semver-compatible version than the one reported in the `Cargo.toml`.

I tried running [`cargo minimal-versions`](https://github.com/taiki-e/cargo-minimal-versions) (which automates a bunch of work you have to do to correctly use `-Z minimal-versions`) and the result was not that good, although most issues were due to dependencies not respecing minimal versions themself.

I found the following issues (though there could be more hidden, see the final note):

- `bevy_ecs`/`bevy_utils` should depend on `tracing 0.1.36`, since that version implemented `Value` for `String` which is used in `bevy_ecs` (although it uses the tracing macros re-exported from `bevy_utils`);
- `bevy_reflect` should depend on `lock_api 0.4.7`, since that version introduced the `const` `new` function which `bevy_reflect` uses (also see #9374, this could be considered a bug in `parking_lot`, since `lock_api` is a transitive dependency through it);
- `bevy_reflect` should depend on `thiserror 1.0.25`, since that version introduced the ability to derive `Error` on non-`'static` types which is used by `bevy_reflect`;
- `bevy_pbr` should depend on `bitflags 2.3.1`, since that version fixes the use of `Self::` in the macro, which is used by `bevy_pbr`;
- `bevy_pbr` should depend on `meshopt 0.2.1` since that version introduced `meshopt::ffi::{meshopt_optimizeMeshlet, simplify_scale}` which are used in `bevy_pbr` (see also #13551);
- `bevy_render` should depend on `image 0.24.3`, since that version introduced the `exr` feature flag (before it was called `openexr`), which is used by `bevy_render` (see #14505);
- `bevy_text` should depend on `glam 0.24.1`, since that version introduced the `Vec2::INFINITY` associated constant (should be fixed by #9653);
- `bevy_render` should depend on `image 0.25.2` since that version introduced `image::ImageReader` used by `bevy_render`, instead it only depends on `image 0.25`
- `tools/example-showcase` should depend on `pbr 1.1.1`, because `pbr 1.1.0` had a bug with imports on Windows;
- `bytemuck` used to declare only a dependency on `bytemuck_derive 1` while it actually uses features of `bytemuck_derive 1.1` and later. This was fixed on `bytemuck 1.12`, but `bevy` crates depend only on older versions of `bytemuck` (`bevy_pbr` depends on `bytemuck 1`, `bevy_ui`, `bevy_core`, `bevy_sprite` and `bevy_render` on `bytemuck 1.5`; also, the `bevy` crate depends on `bytemuck 1.7` but only as a `dev-dependency`);
- some crate depend transitively on `winapi 0.2.5`, but it doesn't compile. `winapi 0.2.7` worked though;
- `gpu_allocator` declares a dependency on `backtrace 0.3`, but it uses features of `backtrace 0.3.3` and later. I would consider this a bug of `gpu_allocator` since the use is internal. This hasn't been fixed yet, though I submitted a PR (Traverse-Research/gpu-allocator#174).

I decided to report the last three issues because, while they are not strictly `bevy`'s fault, they impact building `bevy` with minimal versions.

Note that the analysis must consider the whole workspace together (crates in `tools` included), and this may hide problems in the single crates due to newer dependencies specified by other crates (and this could also apply to dependencies of dependencies...). So for example if `bevy_ecs` declared a dependency on `foo 1` but actually used features from `foo 1.1`, and `bevy_reflect` declared a dependency on `foo 1.1`, then no error would be raised while compiling `bevy_ecs`, even though it technically declared a wrong dependency. To find some of these kind of errors you would have to compile the single crates outside the workspace, which is a lot more work to do. This could be doable just for crates that can be used alone, like `bevy_ecs` and `bevy_reflect` though.

It would be nice if in the future this was automatically tested, to ensure that people don't get weird errors like in #9374, or recently one [posted on Discord](https://discord.com/channels/691052431525675048/1145043501420122132) with `tracing` older than `0.1.36` (which seems to not happen on the master branch likely due to some transitive dependency).