Create a lldb wrapper that downloads and sets everything needed to load a coredump

[mikem8361]

There are a number of steps that are needed to load a coredump in lldb and get SOS to work:

1. Download/supply the "host" program on the lldb command line. This is the native application that .NET app was started: "dotnet", "apphost" or the single-file application binary.
2. Download and make available the libcoreclr.{so,dylib} before lldb is started otherwise the runtime module can't be found by SOS. Unless it is a full core dump, the actual runtime module file needs to be provide for the lldb module enumeration APIs SOS uses to find it.
3. Find and launch the lldb binary with the necessary options.

Live debugging with lldb does not have these problems; only core dump debugging so adding an option to dotnet-dump analyze that does those steps and ends up with lldb command prompt. Even though there is documentation on lldb dump debugging that uses dotnet-symbol to do those first 2 steps, but it seems that one of common problems our customers have is getting all this right.

[kevingosse]

That might be out of scope, but I wonder if it could also extract the binaries from the coredump? (in case of a full coredump)

Maybe I'm missing an option, but when I use LLDB it seems to be unable to read the .so files from the memory dump and require them to be on the disk. Because of this limitation, I now almost exclusively use Windbg to debug my linux coredumps.

[mikem8361]

I'll look into extracting the binaries, but for all the .NET runtime ones like libcoreclr.so this wrapper I'm proposing would be downloaded from the symbol server.