Support per-service api-version mapping for multi-service specs

[Copilot]

The api-version emitter option only accepted a single string, which is silently ignored for multi-service specs and could produce incorrectly-projected SDKs. This extends it to accept a per-service mapping.

api-version now accepts either:

• string — applies only to single-service specs (unchanged).
• dict — maps each service namespace to a version; services not listed default to their latest version. A service may be mapped to all to keep all of its versions.

options:
  "@azure-tools/typespec-client-generator-core":
    api-version:
      Service.A: v1
      Service.B: v2

Changes

• Option type & schema — "api-version" is now string | Record<string, string>; JSON schema updated to ["string", "object"] with oneOf.
• Resolution helper — added resolveApiVersionForNamespace(context, namespace, multiService), the single source of truth for the effective version of a service. Returns undefined (→ use latest) for the multi-service string case and for unmapped services.
• Threaded per-service version through version trimming (removeVersionsLargerThanExplicitlySpecified), decorator filtering (filterApiVersionsWithDecorators), preview filtering (filterPreviewVersion), package-version caching, handleVersioningMutationForGlobalNamespace, and getDefaultApiVersion.
• TCGCContext.apiVersion usages — the remaining direct context.apiVersion === "all" comparisons in package.ts (building the apiVersions map and the deprecated single-service apiVersion metadata) now go through resolveApiVersionForNamespace, so per-service mappings — including a per-service all — are honored.
• Per-service all — handleVersioningMutationForGlobalNamespace skips the versioning mutation for any service whose resolved version is all, keeping all of that service's versions. The global string all early-return is preserved for both single- and multi-service specs.
• Diagnostics — api-version-undefined is now reported per service when a mapped version doesn't exist, instead of only for the single-service case.

Notes

• handleVersioningMutationForGlobalNamespace no longer mutates context.apiVersion as a side channel (previously set to undefined for multi-service and to the latest version on invalid input); the resolution/fallback now happens explicitly at each use site.
• Out-of-range or latest versions continue to fall back to the latest version. A global string all keeps all versions across every service, and a per-service all mapping keeps all versions for that specific service.

[tadelesh]

@copilot Check TCGCContext.apiVersion and its usage. Make it compatible with current new api version map config.

[Copilot]

@copilot Check TCGCContext.apiVersion and its usage. Make it compatible with current new api version map config.

Audited all context.apiVersion usages. The remaining direct context.apiVersion === "all" string comparisons in package.ts didn't account for the new map config (a single-service { Svc: "all" } mapping was treated as a concrete latest version). I routed those through resolveApiVersionForNamespace so per-service mappings — including a per-service "all" — are honored when building the apiVersions map and the deprecated apiVersion metadata. handleVersioningMutationForGlobalNamespace now also skips mutation for any service whose resolved version is "all" (keeping all its versions), while the global string "all" early-return is preserved for single- and multi-service specs. Added a test for the per-service "all" mapping; full tcgc suite (1331 tests) passes. (ae18ccc’s follow-up commit)