[dotnet-svcutil] Migrate Microsoft.Xml importer/exporter to System.Xml types to reduce FrameworkFork dependencies

[imcarolwang]

For issue #5898:
Work has begun on removing the System.Web.Services source fork and transitioning to the official System.Web.Services.Description NuGet package.

A direct replacement was blocked by a type system mismatch: the current implementation depends on a custom Microsoft.Xml fork, while the NuGet package relies on standard System.Xml types. In addition, required importer/exporter logic (e.g., SoapSchemaImporter) exists only in the fork and is not available in modern .NET.

To unblock the migration, a partial extraction and modernization of the Microsoft.Xml layer was completed:

• Retained only the necessary Importer and Exporter classes.
• Rewired these components to operate on standard System.Xml and System.Xml.Schema types.
• Removed reliance on aliased forked namespaces.

During refactoring, regressions affecting RPC/Encoded WSDL scenarios were identified and resolved, including:

• Restored derived type discovery (e.g., xsd:anyType, AdditionalData)
• Added recursion guards to prevent StackOverflowException when analyzing anyType
• Updated attribute generation to recognize standard serialization attributes
• Cleaned up array validation and removed redundant inheritance in generated code

The Microsoft.Xml layer now functions as a lightweight compatibility bridge using standard .NET types, clearing the primary blocker for the eventual removal of the System.Web.Services and the broader framework source fork.