Deprecate and restrict non-MSBuild TaskFactory implementations

### Summary

Deprecate the public interfaces `ITaskFactory` and `ITaskFactory2` and prevent usage of custom task factories that are not internal to MSBuild. The change should error if a custom task factory is specified, gated behind a new change wave opt-out.

### Background and Motivation

Currently, users may implement custom TaskFactories by implementing `ITaskFactory` or `ITaskFactory2` and referencing them in project files. However, these custom implementations are not compatible with upcoming multithreaded MSBuild changes. There is little known usage of this extensibility and maintaining support for arbitrary factories will block future engine work.

### Proposed Feature

1. Annotate `ITaskFactory` and `ITaskFactory2` as deprecated in documentation and code comments.
2. Implement logic (in `src/Build/Instance/TaskRegistry.cs`) to error if a TaskFactory type is specified that is not internal to MSBuild. Only allow built-in factories (e.g., CodeTaskFactory, AssemblyTaskFactory).
3. Gate this error behind a new change wave so that users can opt-out temporarily if their builds depend on custom TaskFactories.
4. Document the change and migration guidance.
5. Add tests to verify the error is thrown behind the change wave and not otherwise.
6. Announce the breaking change and solicit feedback from the community.

Reference: [ChangeWaves-Dev.md](documentation/wiki/ChangeWaves-Dev.md) for implementation guidance on change waves.

### Alternative Designs

Alternative approach: Instead of immediately erroring, emit a warning for one change wave before making it an error in the next wave, giving users more time to migrate. Could also restrict only the most problematic custom factories first and widen the restriction over time. This doesn't seem worthwhile though since we're not aware of any usage.