Introduce a logging facade crate

[jaybosamiya-ms]

This PR implements litebox_util_log, a logging facade that works with both log and tracing, allowing switching between the two backends. It learns a bunch of useful tricks from each of the two:

1. litebox_util_log's syntax for the macros is closer to that of log, in that you say foo:? rather than ?foo (from tracing). The former is nicer because it leads to better match towards Rust-y syntax.
2. litebox_util_log enforces proper structured logging: here it improves upon both log and tracing by disallowing the formatting-based logging approach those allow (both of them support kv/structured logging, but they also allow format-based logging, which leads to harder-to-parse logs; we just disallow this footgun in our facade)
3. litebox_util_log supports spans, which exist in tracing but don't exist in log. It emulates these by inserting span entry/exit events if using the log backend.
4. litebox_util_log supports #[instrument] on functions/methods. log does not have support for this at all, and tracing's support for it is with its own custom syntax that would not mesh well with our log-inspired syntax. So this attribute macro is custom and handles the nicer syntax consistently the way we'd like to have it.
5. litebox_util_log supports :err/:sval/... when using the log backend. These get flattened to Debug on the tracing backend, because tracing does not support these.

The docs & tests demonstrate how to use these to add logging, but in short: add debug!(foo, bar=5; "message") or similar.

Note: this PR does not actually introduce any logging to any of the existing LiteBox crates, that will come in a separate PR. Currently, this is merely introducing the logging facade.

[github-actions]

🤖 SemverChecks 🤖 No breaking API changes detected

Note: this does not mean API is unchanged, or even that there are no breaking changes; simply, none of the detections triggered.