Add trace level logging to most API entry points

[nical]

Checklist

• Run cargo clippy.
• Add change to CHANGELOG.md. See simple instructions inside file.

Description

This PR adds trace-level logs to all or most of the entry points in wgpu-core. A fair amount of debug level logs were converted to trace in the process.

[nical]

I didn't format many of the arguments in the log (mostly the ID of the object in question) in this PR, We should probably format more arguments (the descriptors may be a bit much but there's a fair amount of other useful info) Let me know what you think. I also didn't add much logging to the error paths, I can add them in this PR or a followup.

[teoxoy]

Should these be trace as well?

[nical]

indeed!

[teoxoy]

LGTM

[ErichDonGubler]

LGTM!

The use case I can imagine for the additions specifically appears to be adding context for other log messages. This sort of context-keeping is very similar in domain to tracing's "span"-based model. I wonder if this might be worth exploring for wgpu later; it might obviate things like this PR later, and avoid pitfalls when multiple threads are involved (which I think we do for wgpu right now?).

EDIT: olol, @teoxoy beat me to approval. 😆

[nical]

My main motivation right now is to easily inspect what failing webgpu pages do in firefox's about:logging. If we can get that with spans then 👍

[JMS55]

Did wgpu ever compile-out its logs with a cargo feature? In the past, Bevy has noted that a significant amount of time is wasted in wgpu checking if logs are enabled or not at runtime: bevyengine/bevy#7223. I can't find an issue or PR about it in this repo though.

[nical]

If you depend on the log crate with a feature flag like release_max_level_info, the trace level logs should be discarded at build time. You can do it in bevy directly and that should affect all of the dependencies that use the same version of log.