Give builders two timeouts: one for expected time, another to see if it would have succeeded if we have given it a higher timeout

This is a strategy I've seen used for .NET tests:

1. Fail the build after an expected maximum time it should take to run the tests on the hardware. Keeping this relatively tight prevents PRs from unknowingly massively regressing the time.
2. Keep the build running until a significantly longer timeout expires. The build still fails, but this way, we get to see if the build would succeed if we were to extend the timeout.
   • This is very useful when we do expect a performance regression, or when we don't have time to fix it yet. We can see how much longer we need to extend the timeout for, and whether there's a real hang.

The long tests are long. I just had a build where one longtest succeeded at 53 minutes and another failed due to a 1hr timeout--this strategy would have been useful.

This can be done by giving the AzDO job the long timeout, and make eng/run.ps1 run-builder keep track of the shorter timeout.

Start by reading eng/run.ps1, especially the run-builder path, and inspect how the AzDO job currently applies its timeout. Define the shorter expected-runtime failure separately from the longer build-running timeout. Done means a build reports an early timeout while continuing until the longer limit, distinguishing a slow success from a hang.