tp: Add trace_diagnostics table to detect bad trace configs (#6576)

Introduce a new `trace_diagnostics` table that surfaces likely
misconfigurations in a trace's TraceConfig, so the UI (and any other
consumer) can warn users about configs that hurt trace quality. Each row
is a (name, description, remediation, confidence) tuple scoped to the
current trace and machine.

Detection runs in C++ because the TraceConfig is only reachable in a
structured form there: only the opaque pbtxt survives into SQL. A new
per-(trace, machine) TraceDiagnosticsTracker captures the raw config at
parse time (MetadataModule) and runs a growing corpus of detection rules
at finalization, once trace bounds and clocks are available. Rules are
plain functions; adding one is a single entry in kRules[]. Shared
machinery (emitting rows, iterating ftrace/data-source configs, deriving
values from the context, scanning stats) lives in TraceDiagnosticsHelper
to keep the rule file focused on the detection logic.

Initial rules cover the most common ftrace/profiling mistakes:
  - tiny ftrace buffer_size_kb (size-proportional confidence)
  - low ftrace drain bandwidth (buffer_size_kb / drain_period_ms)
  - extreme drain_period_ms
  - syscall tracing without a syscall_events filter
  - preserve_ftrace_buffer with tracing started long after boot
  - sched_switch without compact_sched
  - events needing symbolize_ksyms (and enable_function_graph)
  - DISCARD buffers backing ftrace/track_event while streaming to a file
  - atrace_apps: "*" with many categories (when data was lost)
  - heapprofd sampling_interval_bytes below 100 KB

Buffer/bandwidth rules escalate their confidence when the trace actually
recorded ftrace data loss, and the heapprofd rule escalates on heapprofd
errors.