Support shorthand for #[emit::as_debug]

[KodrAus]

The case of logging values with their debug representation while building or testing code is common and important enough that we may want a shorthand for it. Instead of having to write:

emit::debug!("received {#[emit::as_debug] message} from queue");

you could instead write:

emit::debug!("received {message:?} from queue");

The ident:? pattern would expand to #[emit::as_debug] ident. You wouldn't be able to combine it with other attributes or format flags, and other attributes wouldn't have a shorthand. We may also restrict it to the debug! macro. The goal is just to make it easier to pepper temporary debug-style logging in code you're actively working on. Long-term logging should prefer serialized or display-formatted values over the debug format.

[KodrAus]

An alternative design here is another macro: emit::dbg!(). It could accept either an expr, like the standard dbg!(), or a regular template. The difference to emit::debug!() would be:

1. A plain expr captures using fmt::Debug in a property called value.
2. A regular template also captures any properties using fmt::Debug. The template form would be preferred over the expr form (string literals would be ambiguous).
3. The panic::location is also captured.

This would make emit::dbg!() largely compatible with the standard dbg!() as a quick-and-dirty way to pepper temporary debugging aids through a program. These can then be easily found later with a search for 'dbg' to remove them or replace them with longer-lived diagnostics.

[nblumhardt]

Just to add another perspective, for me the main advantage of :? is that it's consistent with how format! is used; in the back of my mind I keep expecting it to work, and needing to flip over to #[emit::as_debug] pulls me out of the familiar/predictable Rust-y API and into emit's specifics. I'd probably not gain any benefit from the alternative dbg! solution.

[KodrAus]

Yeh, the balance I'm trying to strike is that debug is convenient for quick debugging, especially when working with a lot of internal types that don't implement display, but I think is non-ideal for long-term logging. In that case, you're better off with a deliberate and stable format from display, or a structured format from serde. I was hoping a different macro for quick-and-dirty debugging would put you in a different mindset, so your long-lived events would be higher quality.