PMI: options for using local .Net Core builds

As part of dev inner loop workflow it will be common to want to run PMI on local .Net Core builds. Here are some initial ideas on various approaches we could take.

For diffing and correctness checking we would like to use a checked build of the jit. So we either need a jit build that is compatible with the host CLI, or else we need a way to invoke a simpler locally built runner (say corerun).

For robustness we initially will likely use `DRIVEALL` to run the locally built jit in a child process, so we can push past asserts.

Once a particular method becomes interesting (from an assert or asm diff) we can use `PREPONE` to look at just that method. Currently that does not use a child process. So perhaps we need a `DRIVEONE` to parallel `DRIVEALL`.

If we go the CLI route, we can use the instructions in coreclr for using local nuget packages. This perhaps is most simply done by cloning the project file and adding new entries for the runtime. Or we can publish and then patch. It might make sense to always run the jit under test as an altjit. This would mean the cross-arch and self-arch jitting workflows would be the same.

Benchmark Dot Net seemingly solves similar issues and it might be interesting to consider adopting their approach; this would conceptually allow cross-runtime diffing (say comparing .net core vs .net framework codegen, or .net vs mono).

We probably want custom `complus` settings to apply only to the methods jitted via PMI. Even if we prejit/crossgen PMI.exe there will still be some residual jitting from SIMD methods in the core library. So we might need an assembly-inclusive altjit filter (currently there's only an exclusion list).