We don't emit signposts until something else has set them up, to avoid deadlocks when we're running in code that's involved in setting them up. But this means that Instruments will miss Concurrency events in a simple program that doesn't otherwise trigger setup of the logging system.
Since we must be in a platform binary if we're running in code that's setting up logging, we can check for that and only be lazy in platform binaries. Non-platform binaries can safely emit signposts eagerly.
rdar://142483658
Emitting a signpost for the first time can trigger lazy setup of the logging system, and doing this in the wrong context can cause deadlocks. Check to see if the logging system is already set up, and only emit signposts if it has been to avoid triggering this.
As it's hard to determine if the "is it set up?" function is available in the SDK we're building against, only do this in OS builds, as it's not particularly useful in local builds.
rdar://124620772
We can't use os_log functionality in logd, diagnosticd, or notifyd. Check for them and disable tracing in those processes.
Add a new TracingCommon.h for common code shared between swiftCore and swift_Concurrency tracing. Add a single function that checks if tracing should be enabled, which now checks if os_signpost_enabled is available, and if the process is one of these. Modify the tracing code to check this before creating os_log objects.
rdar://124226334
