This changes our bootstrap compiler to run as a 32 bit process in the 32
bit CI runs. The intent of this runs is to validate we can function on
32 bit systems and that should extend to the compiler as well.

This can help us identify the rare cases where we emit code that doesn't
perform well on the 32 bit JIT, or just outright crashes.

The CI specific setup in build.ps1 had gotten a bit unweildly. So much
so that we had two `if ($ci)` blocks back to back.

This factors out much of the logic into a helper method and cleans up
the main method to have a single block.

When the optimization data isn't available our build will terminate
with VBCSCompiler still being alive and holding a handle to
Build.Server.Log. That handle causes an error during publishing.

This error shouldn't happen as the file is open with
`FileShare.ReadWrite` hence publish can access the file. This can be
demonstrated locally by using any number of tools to open the file while
a build is running. Likely publish is looking for exclusive access here
and that's why the error occurs.

In any case though we should be killing our spawned processes at the end
of the job anyways in CI. Leaving behind server processes for the next
run is just asking for trouble.

https://github.com/Microsoft/azure-pipelines-tasks/issues/9994

Two space indent is an abomination but it's the standard that Arcade
chose. Moving our Powershell to be consistent with the standard.

This cleans up all of the PROTOTYPE comments around using the 3.0 SDK
inside the DIM branch.

Have to disable quiet restore explicitly on local dev machines when
doing a bootstrap build to work around this arcade issue:
https://github.com/dotnet/arcade/issues/2220

* Update PowerShell version

* Exit build.ps1 if PowerShell version less than 5

* Move check, tidy up formatting

This reverts commit 726c2bc0, reversing
changes made to f51b5490.

* Read IBC and VS bootstrapper info from PublishData.json

* Fix IBC directory path

We have two folders we use during a test run: we put our XML result
files in one folder for the Azure DevOps task to specifically catch,
and all other log files in a different folder which we upload as a
generic artifact. We were putting log files in the wrong folder so we
never uploaded them as artifacts.

Nothing other than one suspicious test in SolutionTests.cs used any
of this, so it's easier to move it all and keep things isolated.

* Arcade SDK 1.0.0-beta.19054.11

* Consolidate OptProf scripts

* Use raw IBC data from VSTS drop