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.