Crank runner for Helix

[caaavik-msft]

This PR contains initial work around making it so that devs inside Microsoft can use crank to schedule performance runs on Helix machines locally, rather than having to do them through CI pipelines only.

Currently, a lot of the logic around running performance tests are stored in a mix of Azure Pipelines yaml files, shell scripts, powershell scripts, python scripts, MSBuild project files across both the dotnet/runtime and dotnet/performance repositories. This PR attempts to move as much of that logic as possible into python scripts so that they can be run outside the context of a CI pipeline, and eventually we can update our CI pipelines to run these python scripts instead.

I also took this opportunity to fix up our python scripts to have proper type hints set, as well as configuring some settings so that we get good autocompletion and linting inside VSCode.

I have set up a crank agent that runs inside corpnet, which those inside Microsoft on a corpnet-connected machine will be able to use. For Microsoft employees working remotely, they can either use a DevBox (which has access to corpnet), or they can talk to a member of the .NET Performance Team to get an Azure Relay connection string which will allow communication outside corpnet.

An example of using crank to schedule a performance run on a remote machine is:

crank --config .\helix.yml --scenario micro --profile win-x64 --variable bdnArgs="--filter *Linq*" --profile msft-internal --variable buildNumber="caaavik-20230804.2"

This will run all the Linq microbenchmarks on a win-x64 helix machine against a local pre-built corerun. The results will be returned back and displayed in the terminal, it may also be uploaded to the Azure Data Explorer to view there.

[caaavik-msft]

Some things that still need fixing before this can be merged:

• I need to add some documentation on how to use this
• There are a few bugs left with running scenarios I need to fix
• I also don't have support just yet for getting the scenarios to send the results back to crank, they will be uploaded to ADX though.
• I had to add an exception for .git in the .gitignore otherwise it would not get uploaded to the crank agent where we run git commands

[DrewScoggins]

LGTM. Obviously there is a lot here, and I would be lying if I said that I now fully understand all of the intricacies. Overall, the change looks good though and I am confident that this shouldn't cause any breakage in our existing data pipelines.

We should make sure that we are being vigilant as we roll this out to ensure that data is ending up in the correct place, both for existing runs and new ones that get queued through this process.