Support running 'classic' MSBuild Tasks in Thread-based worker nodes

[baronfel]

Summary

With the new Thread-backed worker node + new thread-safe Task API, we face a bit of an adoption hurdle. Users must

• Update their MSBuild package dependencies to a very recent version
• Create/maintain parallel versions of their Tasks
• Update UsingTask logic to choose the correct Task implementations in various MSBuild hosting scenarios

This means that anyone attempting to participate in multithreaded builds efficiently will by necessity cut off a long tail of MSBuild/IDE support.

Background and Motivation

To lower this adoption hurdle, we should enable the Thread-backed worker node's TaskHost to recognize and wrap old-style Tasks in the Thread-based semantics, so that authors that are reasonably confident that they do not do stateful actions in their Tasks can easily participate in multithreaded builds while not forsaking their existing legacy MSBuild/IDE support.

Proposed Feature

Today a user opts into the new TaskHost mode by doing <insert gesture here>. Doing this makes the TaskHost look for an implementation of the new Task interface, load it, and invoke it. Broadly, we should expand the TaskHost's capabilities to recognize the old Task interface, load it, and invoke it as well. We should do very little validation of the behaviors of a Task loaded in this way.

We should collect build-level telemetry of how many Tasks are loaded in this way - over time we would like to see this number trend down.

This compatibility behavior should be enabled by default for the first release(s) of Multithreaded MSBuild, but the goal should be to deprecate it and start giving informational/warning messages shortly after release. The final goal would be to disable the compatibility bridge by default ~2 years after the initial release of Multithreaded MSBuild. A Trait would be made available as a way to re-enable the compatibility bridge for specific use cases, but we should aim at sunsetting it within ~5 years.

Alternative Designs

No response