Implement support for most common workflow (RELEASE assemblies and CHECKED jit)

[AndyAyersMS]

We care mostly about measurements on RELEASE builds of the core library and framework assemblies.

Unfortunately jit dasm won't work in RELEASE builds of CoreCLR, so we need to blend in some parts of CHECKED builds (ideally just the clrjit.dll). Would be nice if the tool handled this automatically and warned if necessary parts were missing.

[russellhadley]

@AndyAyersMS, how is RELEASE different than CHECKED for assemblies. For the framework assemblies I thought we were already pulling the release packages - do you mean the tests themselves? I believe today that crossgen still has the jit linked in staticly so I'm expecting that a checked build of crossgen will suffice. I think we will enable the clrjit.dll for crossgen - the works just not done yet.

[AndyAyersMS]

For framework assemblies there may be no difference, but the core assembly will generally be different between RELEASE and CHECKED. See for instance dotnet/coreclr#6030. The core assembly's prejit image influences codegen in all subsequent assemblies, so it is important to get off on the right foot.

[russellhadley]

@AndyAyersMS That shows the different between Debug and Release/Checked so I'm assuming that you mean the corlib has different ifdefs between Release and Checked and thats what the issue is. Is that correct? (I didn't think that there was a formal CHECKED build separate from RELEASE for anyone but the JIT...)

[AndyAyersMS]

There are important differences beteen RELEASE and CHECKED both in the set of defines and in the debug type. Debug type full inhibits optimization by the jit, IIRC.

[BruceForstall]

@AndyAyersMS Is this still valid? With my recent jit-diff changes, RELEASE is preferred for some defaults. But you certainly can always choose release for those things, and CHECKED for the JIT.

[AndyAyersMS]

We've had this capability for a while now. Thanks for fixing it....