Make tracing Optional for bevy_utils

[bushrat011899]

Objective

• Allows bevy_utils to compile on platforms without atomic CAS operations (e.g., GameBoy Advance thumbv4t-none-eabi)
• Contributes to Tracking Issue: MVP no_std Bevy #15460

Solution

• Made tracing optional (behind the tracing feature, enabled by default).
• Switched to using log within bevy_utils, and exported it as tracing.

Testing

• cargo build --target thumbv4t-none-eabi

Migration Guide

If you were using bevy_utils with default features disabled, and you relied on the tracing re-export, and you relied on a tracing item that is not available in log, enable the tracing feature.

Notes

tracing has built-in support for capturing logs from log and this is enabled by default. The biggest loss going from log to tracing is the loss of info_span/etc. Otherwise, the crates are largely identical in behaviour, with log having no dependencies and more popularity on crates.io.

[alice-i-cecile]

I don't quite follow the strategy here. It looks like we're unconditionally calling the log variants, but we want to call the tracing ones if and only if the feature is enabled (just like before).

[bushrat011899]

I've also updated the migration guide since this is now only just barely a breaking change.

[Elabajaba]

Just a small sidenote, log has a much higher performance overhead than tracing for spammy logs and log filtering (see gfx-rs/wgpu#6046 (comment) for why).

[mockersf]

I think the re-exporting of log as tracing should be avoided.

I would prefer to take the breaking change in this PR, and re-exports the common functions and macros between tracing and log as bevy_utils::log, and use that through the engine

[bushrat011899]

These are both excellent points. I will update the documentation to indicate that users should prefer to use the tracing feature unless they must disable it. As for the breaking change, I agree. I will update the PR to expose the common items in log and tracing from bevy_utils::log. For items which are exclusively available from tracing, should we export those from bevy_utils::log, only export them from bevy_utils::tracing, or re-export the whole tracing module (causing items like trace! to be exported twice)?

I'm leaning towards only exporting tracing exclusive items from bevy_utils::tracing, and everything else from bevy_utils::log.