Consider moving system info from `bevy_diagnostics` into a new crate

## Objective

Improve Windows build times by making fewer crates depend on `sysinfo` and `windows`.

## Background

When I do a clean `cargo build` of Bevy on Windows, the critical path is:

```sh
windows -> sysinfo -> bevy_diagnostic -> multiple bevy crates -> bevy_render -> bevy_pbr
```

The `sysinfo` crate is used by the `SystemInfo` resource and `SystemInformationDiagnosticsPlugin` in `bevy_diagnostics`. However, the crates that depend on `bevy_diagnostics` do not use these parts - the only exception is `bevy_internal`, which adds them via `bevy_diagnostic:::DiagnosticsPlugin`.

Let's say these parts were moved to a separate `bevy_diagnostics_sysinfo` crate. That means many Bevy crates would no longer transitively depend on `sysinfo` and `windows`, shortening the critical path. The only crate to depend on `bevy_diagnostics_sysinfo` would be `bevy_internal`, which is compiled very late since it depends on everything.

## Testing

I simulated the change by disabling the `sysinfo_plugin` feature. This isn't quite correct, but should give a rough idea of the best case scenario:

- Windows 10, Desktop Zen 4 (12c), cargo clean and build:
- Before: **127s**
- After: **123s (-3%)**
- Same, but with `-j 3` to simulate CI:
- Before: **209s**
- After: **207s (-1%)**

## Conclusion

We get a small win, but not for CI. So I'd say the juice might not be worth the squeeze right now?

## But Maybe?

The gains are small because the critical path shifts to this:

```sh
windows -> gpu-allocator -> wgpu-hal -> wgpu-core -> wgpu -> bevy_render -> bevy_pbr
```

If `bevy_render` and `bevy_pbr` get faster or are split up then this issue might have more impact. Note that those crates have got [suspiciously slow](https://github.com/bevyengine/bevy/issues/23642) over the last few cycles. If that's fixed then maybe this issue is worth revisiting.

## Alternatives

- The `sysinfo` dependency could be removed entirely: https://github.com/bevyengine/bevy/issues/11929 (that bug was closed after the `sysinfo_plugin` feature was added, but the feature is enabled by default).
- The `sysinfo_plugin` feature could be disabled by default, but then we'd lose the CPU/OS logging that's useful for bug reports (see `impl Default for SystemInfo`).