This PR updates End-of-Life Ubuntu buildtools container references to the supported Ubuntu 22.04 version.

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: steveisok <471438+steveisok@users.noreply.github.com>
Co-authored-by: Juan Hoyos <19413848+hoyosjs@users.noreply.github.com>

Instead of hardcoding several dozen llvm versions from 3.5 to 21, lets
just use the latest available llvm version from LLDB.h path then find
the matching liblldb version.

---------

Co-authored-by: Noah Falk <noahfalk@users.noreply.github.com>

It's stated that none of the `process-id`, `name`, or `diagnostic-port`
options should be configured when launching a child process with
`dotnet-trace collect ... -- <child process to launch>`, yet the check
only errors when all are configured.

Additionally makes the exclusive check on `process-id`, `name`,
`diagnosic-port`, and `dsrouter` more readable.

### Before
```
SUCCESS
PS C:\Users\mihw\source\repos\mdh1418\diagnostics\latest> .\artifacts\bin\dotnet-trace\Debug\net8.0\dotnet-trace.exe collect -p 1418 --show-child-io  -- dotnet package search json
The runtime has been configured to pause during startup and is awaiting a Diagnostics IPC ResumeStartup command from a Diagnostic Port.
DOTNET_DiagnosticPorts="dotnet-trace-26020-20250616_135956.socket,suspend,connect"
DOTNET_DefaultDiagnosticPortSuspend=0

FAIL
PS C:\Users\mihw\source\repos\mdh1418\diagnostics\latest> .\artifacts\bin\dotnet-trace\Debug\net8.0\dotnet-trace.exe collect -p 1418 --show-child-io -n mihw --dport whim  -- dotnet package search json
None of the --name, --process-id, or --diagnostic-port options may be specified when launching a child process.

SUCCESS
PS C:\Users\mihw\source\repos\mdh1418\diagnostics\latest> .\artifacts\bin\dotnet-trace\Debug\net8.0\dotnet-trace.exe collect -p 1418 --show-child-io -n mihw  -- dotnet package search json             
The runtime has been configured to pause during startup and is awaiting a Diagnostics IPC ResumeStartup command from a Diagnostic Port.
DOTNET_DiagnosticPorts="dotnet-trace-27244-20250616_140018.socket,suspend,connect"
DOTNET_DefaultDiagnosticPortSuspend=0
```

### After
```
FAIL
PS C:\Users\mihw\source\repos\mdh1418\diagnostics\latest> .\artifacts\bin\dotnet-trace\Debug\net8.0\dotnet-trace.exe collect -p 1418 --show-child-io  -- dotnet package search json                 
None of the --name, --process-id, or --diagnostic-port options may be specified when launching a child process.

FAIL
PS C:\Users\mihw\source\repos\mdh1418\diagnostics\latest> .\artifacts\bin\dotnet-trace\Debug\net8.0\dotnet-trace.exe collect -p 1418 --show-child-io -n mihw --dport whim  -- dotnet package search json
None of the --name, --process-id, or --diagnostic-port options may be specified when launching a child process.

FAIL
PS C:\Users\mihw\source\repos\mdh1418\diagnostics\latest> .\artifacts\bin\dotnet-trace\Debug\net8.0\dotnet-trace.exe collect -p 1418 --show-child-io -n mihw  -- dotnet package search json         
None of the --name, --process-id, or --diagnostic-port options may be specified when launching a child process.
```

Partly addresses #5501

Child processes started by diagnostic tooling set a
`DOTNET_DiagnosticPort` environment variable, specifying only the path.
The runtime [defaults to a connect type port in suspend
mode](https://github.com/dotnet/runtime/blob/22ccb0563cbb79e950b8d8e2d8bed306b125e7d8/src/native/eventpipe/ds-ipc.c#L628-L637),
which isn't clear from the end user's viewpoint, as [logging will only
reveal the DiagnosticPort
value](https://github.com/dotnet/runtime/blob/22ccb0563cbb79e950b8d8e2d8bed306b125e7d8/src/coreclr/vm/eventing/eventpipe/ds-rt-coreclr.h#L390-L412).
Instead, we can mitigate confusion by explicitly setting the config from
the tooling side.

### Before
```
The runtime has been configured to pause during startup and is awaiting a Diagnostics IPC ResumeStartup command from a Diagnostic Port.
DOTNET_DiagnosticPorts="dotnet-trace-48696-20250614_161420.socket"
DOTNET_DefaultDiagnosticPortSuspend=0
```

### Now
```
The runtime has been configured to pause during startup and is awaiting a Diagnostics IPC ResumeStartup command from a Diagnostic Port.
DOTNET_DiagnosticPorts="dotnet-trace-29004-20250616_134924.socket,suspend,connect"
DOTNET_DefaultDiagnosticPortSuspend=0
```

… session (#5454)

In .NET 10, the EventPipe infrastructure will be leveraged to support
[user_events](https://docs.kernel.org/trace/user_events.html).

This PR documents the protocol for enabling a user_events-based
EventPipe Session through the Diagnostics IPC protocol, where a new
EventPipe Command ID `CollectTracing5` will accept necessary tracepoint
configuration.

As the user_events EventPipe session is not streaming based, the payload
is expected to first encode a `uint output_format` to denote the session
format (streaming vs user_events). Afterwards, only relevant session
configuration options are to be encoded, outlined at the top of the
`EventPipe Commands` section in the `Streaming Session` section,
`User_events Session` section, and `Session Providers` section.

For user_events EventPipe sessions, an additional tracepoint_config is
to be encoded, to map Event IDs to tracepoints.
This protocol expects the Client to have access to the
`user_events_data` file in order to enable configuring a `user_event`
EventPipe session, and expects the SCM_RIGHTS to the `user_events_data`
file descriptor to be sent in the continuation stream.

Additionally, as `user_events` does not support callbacks, a new
event_filter config is expected to be encoded in `CollectTracing5`, to
act as an allow/deny list of Event IDs that will apply post
keyword/level filter.

Pretty much just adjusts what we had for Project N:

* `IsProjectN` is not true for native AOT because we use the same
provider GUID as JIT-based CoreCLR and not Project N (which is by
design)
* It is still possible to handle both Project N and native AOT the same
way where it matters because both Project N and native AOT emit the same
flags (`TypeFlags.ModuleBaseAddress` and `ModuleFlags.Native`)
* Looks like Project N GCDump always relied on Windows kernel module
load data only. I'm adding a path that can also use our own module load
events (Project N also generates those)

Cc @dotnet/ilc-contrib

Sync changes made for dotnet/runtime#116072 over
to diagnostics repo