obs: opt into execution traces for diagnostics bundles

**Is your feature request related to a problem? Please describe.**

Field, Support and Engineering regularly spend extensive amounts of time diagnosing slow statement/transaction executions. Some classes of root causes - NUMA, garbage collection overhead, locking issues - are difficult to glean from CRDB traces alone. When standard analysis fails, we usually ask for "statement diagnostics bundle with overlapping execution trace", the latter being a recording of the Go scheduler view of goroutine events which serves as a "big hammer" that, in combination with a specific slow execution, can usually point at deeper root causes. Unfortunately, it is difficult for customers to reliably provide this data. The collection is fairly manual and as a result, error-prone. This adds redundant delays and round-trips between the customer and CRL to the troubleshooting process, which is inefficient. The Obs team already added https://github.com/cockroachdb/cockroach/pull/149373 which allows continuously capturing execution traces using cluster settings. This is helpful, but still requires manual setup and collection, and importantly, always requires "already having exhausted the available venues" before being a path that is taken. We could do "one better" and fully integrate execution trace collection with the user flow to collect stmt/txn diagnostics bundles: users can easily collect this information, perhaps even by default, and engineers don't have to spend time sorting through large amounts of execution traces to identify the correct ones to investigate.

**Describe the solution you'd like**

A new option to collect an overlapping execution trace appears in the statement diagnostics modal (similar for transaction diagnostics, once we have it).

When that option is selected, trace spans created in service of this diagnostics request are tagged as desiring an execution trace.
On every node on which such a trace span is active, execution trace flight recording is enabled, and execution traces are retained (subject to a retention period and size limit), with each such file having its reference added to the trace span (as a structured payload). Note that these execution traces are not necessarily persisted to disk at this point - only when the CRDB trace actually matches the conditions for the diagnostics bundle (e.g. sufficiently slow) does the diagnostics code resolve the references to existing execution traces and collects them, to make them available as part of the corresponding bundle.

The earlier prototype https://github.com/cockroachdb/cockroach/pull/146873 had a relatively sophisticated attempt at providing the flight recording infrastructure necessary to accommodate the flow above.

**Describe alternatives you've considered**

**Additional context**

- https://github.com/cockroachdb/cockroach/issues/97215 is the original issue tracking this idea, and was marked as completed before the desired functionality was fully implemented. Referenced in that issue are numerous support incidents that would've benefited from fully integrated execution trace integration.

- https://github.com/cockroachlabs/support/issues/3383 saw much time spent obtaining execution traces. The customer wasn't even running with the change that allows using the cluster settings, but the incident still serves as an example of one in which we might save a lot of time had execution traces been available with lower friction early in the process.

Jira issue: CRDB-58910