[http-client-csharp] Normalize acronyms in ordinary operation parameter names #12071

Summary

Extend acronym normalization to ordinary operation parameters. Property-derived constructor/model-factory parameters already benefit from normalized property names and IPv4/IPv6 camel-casing; that does not cover parameters originating directly from an operation.

Follow-up to Azure/azure-sdk-for-net#61944 and #11641. Related prior work: #11673, #11714, and #11719.

Current implementation

Source inspected at 9ab53f765aca1c27b623c7e5775eb9929272ec39:

• operation-converter.ts passes parameter names and isExactName through to the input model.
• ParameterProvider(InputParameter) retains the input name except for typed date/time naming; it does not apply general acronym normalization.
• TypeFactory.CreateParameterCore is a protected virtual factory hook, but compatibility decisions also need the enclosing method/contract context.
• PropertyProvider.AsParameter follows a different path: normalized property name followed by ToVariableName().

Desired behavior

For new, non-exact operation parameters without a matching previous public signature, names such as sourceIpAddress, targetDbName, and guestOsType should become sourceIPAddress, targetDBName, and guestOSType.

Preserve valid camelCase at the beginning: ipAddress, dbName, osType, ipv4Address, and ipv6Address must not become PascalCase. Previously shipped or exact iPv4/iPv6 names must remain unchanged. These are source-derived examples rather than executed generation results.

Acceptance criteria

• Reuse the same boundary-aware rules as other supported symbol surfaces, with correct camelCase conversion for parameters.
• Cover ordinary query/path/header/body method parameters and their protocol/convenience and sync/async projections; do not apply public-name normalization to serialized wire names.
• Preserve exact names, custom signatures, and last-contract parameter names, including existing model-factory/constructor compatibility behavior. Parameter names matter to named-argument source compatibility.
• Keep argument references, request mappings, spread/grouped parameter mappings, validation code, and XML parameter documentation consistent with emitted signatures.
• Add extensive tests for leading and embedded acronyms, IPv4/IPv6, repeated occurrences, negative boundaries, canonical spellings, exact/customized/published signatures, and method variants.
• Keep already-supported property-derived parameter naming working; do not reinterpret legacy names as new-contract names.

Scope boundary

Management also creates parameters directly from resource path metadata and applies a separate body-name fallback. Those paths bypass the shared input-parameter factory and need management-specific follow-ups under Azure/azure-sdk-for-net#61944.