Create and document the lifetime and correct usage of static members in Tasks

### Summary

When MSBuild Server (and to a lesser degree Multithreaded MSBuild) is enabled, Tasks that depend on static singletons may exhibit behavior that violates some of the invariants of those modes - an example of this is the NuGet [PluginManager](https://github.com/NuGet/NuGet.Client/blob/c903a35282bad96d60ada3766775caac93a9f7e7/src/NuGet.Core/NuGet.Protocol/Plugins/PluginManager.cs#L27), or the [EnvironmentWrapper](https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.Common/EnvironmentVariableWrapper.cs#L11), both of which are static singletons that would remain alive for longer durations than expected.

### Background and Motivation

These statics can leak data across builds, or simply cache data for a duration not expected by the Task authors, and implicitly violate the lifetime expectations of the MSBuild Server node/Multithreaded build nodes.

### Proposed Feature

We need to provide guidance for Task authors about what the proper use of statics is, and how to ensure that these are cleaned up/re-initialized/etc at appropriate lifecycle points for the MSBuild Server/Multithreaded lifecycles.

We _also_ need to expose additional MSBuild flags/properties for:

* is the build multithreaded
* is the build server mode

because in both of these cases, the central scheduler node is _also_ a worker node, so for Tasks like RestoreTask that operate on the central node _always_, they will persist. To fix this, in either MT or Server, the Task needs a UsingTask change to kick out to a TaskHost.

### Alternative Designs

_No response_