`dotnet-trace` on containers

## Background and Motivation

This is for Linux, when using `dotnet-trace` in PID connect mode, e.g `dotnet-trace collect --process-id XXX ...`.

`dotnet-trace` attempts to connect to the transport pipe in `/tmp` of the mount namespace it's currently running in. If the target PID runs in a container (or if `dotnet-trace` itself runs in a container), then its mount namespace is different than the mount namespace of `dotnet-trace`, and we'll not find its pipe.

This is raised in https://github.com/dotnet/diagnostics/issues/810 and the proposed solution (at least from my skimming) is to mount the `/tmp` such that it's accessible on the host.

## Proposed Feature

Another solution that I'm proposing is to access the `/tmp` of the container, via `/proc/pid/root/tmp`, in case the target process runs in a different mount namespace (easily checked by comparing the `/proc/pid/ns/mnt` file of `dotnet-trace` to the one of the process).

We're using this "trick" in our [gProfiler](https://github.com/Granulate/gprofiler) (see usage [here](https://github.com/Granulate/gprofiler/blob/f55c9fbd65bb607ad332d99cc5008e709f2ffd79/gprofiler/profilers/dotnet.py#L106)), by changing the `TMPDIR` variable which is respected by `dotnet-trace`, and it's proved itself to work, so I figured we could place this logic in upstream and have it fixed for everyone :)

I searched through the code a bit and found [PAL_GetTransportName](https://github.com/dotnet/diagnostics/blob/38de874d9c8e0e3cfa021d8dee72814c4e36b080/src/shared/pal/src/thread/process.cpp#L1882) which appears to be the relevant function for this change. It also seems to handle the same concept for MacOS (using `GetApplicationContainerFolder`). I figure that'd be the place to put the matching Linux support.

If you think this could be a good addition, I'm happy to implement this change.

## Usage Examples

Profiling/tracing a process running in a container.