Publish Uri and UriBuilder threat models

[MihaZupan]

These are a mix of threat model / implementation design doc.

I'll link to this from public docs once it's merged.
The Fuzzing section refers to a non-existent file for now since I'm waiting on #123932 to get merged first.

[dotnet-policy-service]

Tagging subscribers to this area: @karelz, @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This pull request adds comprehensive threat model and implementation design documentation for System.Uri and System.UriBuilder. These documents are intended to be referenced from public documentation and provide detailed security considerations, implementation details, and usage guidelines for developers working with URI parsing and construction.

Changes:

• Adds detailed threat model documentation for System.Uri covering parsing behavior, security considerations, algorithmic complexity, thread safety, and custom parsers
• Adds threat model documentation for System.UriBuilder covering construction, property validation, and security considerations
• Documents are placed in src/libraries/System.Private.Uri/docs/ following the pattern of other security documentation in the repository

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
src/libraries/System.Private.Uri/docs/System.Uri Threat Model.md	Comprehensive 517-line threat model covering Uri parsing phases, component validation, normalization, security considerations, algorithmic complexity guarantees, thread safety, custom parsers, and fuzzing
src/libraries/System.Private.Uri/docs/System.UriBuilder Threat Model.md	141-line threat model documenting UriBuilder's mutable builder pattern, component validation, property behavior, and security considerations for URI construction

[AustinWise]

Suggested change

	The set of schemes that are recognized by the implementation is not documented and may change in the future (but currently includes http, https, ftp, file, ...). The current set includes schemes such as http, https, wss, ftp, file, etc.
	The set of schemes that are recognized by the implementation is not documented and may change in the future. The current set includes schemes such as http, https, wss, ftp, file, etc.

It seems redundant to list the schemes twice.

[AustinWise]

Suggested change

	Another option that is practically never used in practice is to register a custom implementation derived from `UriParser` which can bypasses internal parsing logic. That implementation is then responsible for creating `Uri` instances for that scheme, doing the parsing, and returning results by overriding the `GetComponents` functionality.
	Another option that is practically never used is to register a custom implementation derived from `UriParser` which can bypasses internal parsing logic. That implementation is then responsible for creating `Uri` instances for that scheme, doing the parsing, and returning results by overriding the `GetComponents` functionality.

"practically in practice" seems redundant.