profiling: Add abstraction over tracing-rs (#40160)

There are multiple motivating factors for this change:

1. `tracing-rs` can and is commonly used for structured logging, to gain
understanding in what is happening in concurrent code. We would like to
attempt to make a distinction of the performance tracing related usage
and the logging related usage.
2. This reduces boilerplate code. We don't have to feature guard every
span anymore, since the macro will do it for us.
3. This makes it easier to add multiple options for the trace backend
(i.e. exchanging tracing-rs for hitrace on OpenHarmony or System Tracing
in Android), or something entirely custom.
4. This makes it easier to add further compile-time options to control
the amount of tracing. E.g. a future PR could add options to enable
tracing based on environment variables set at compile time. Tracing adds
runtime overhead, even if the runtime switch is disabled, so having more
fine-grained options to partially enabled tracing could be useful.

Testing: Tested manually by building with and without the `tracing`
feature. In CI we also build with the tracing feature in the HarmonyOS
build. We don't have any automated tests for the correctness / presence
of the traced entries.

---------

Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>

components/script/dom/css/cssstylesheet.rs

@@ -291,8 +291,7 @@ impl CSSStyleSheet {
 
         self.will_modify();
 
-        #[cfg(feature = "tracing")]
-        let _span = tracing::trace_span!("ParseStylesheet", servo_profiling = true).entered();
+        let _span = profile_traits::trace_span!("ParseStylesheet").entered();
         let sheet = self.style_stylesheet();
         let new_contents = StylesheetContents::from_str(
             &text,