Eliminate Per-Operation Lambdas for Constant Pool Overflow Fix

[S-Saranya1]

Motivation and Context

The interceptor-to-pipeline-stages migration PR #7017 introduced two inline lambdas per operation in generated service clients for endpoint and auth scheme resolution. Each lambda adds ~8-16 constant pool entries to the class file. For services with a large number of operations (800+), this adds enough constant pool entries to push the generated async client class past the JVM's hard 65,535 entry limit, causing a compilation failure:
too many constants

PR #7111 provided a short-term fix using factory methods, reducing the cost to ~2-3 entries per operation. This PR implements the long-term fix to eliminate per-operation lambdas entirely, reducing the constant pool cost from resolvers to zero per operation.

Modifications

• The resolver methods (resolveEndpoint, resolveAuthSchemeOptions) need the operation name to function. Previously this was passed via lambda capture. Now they read it directly from ExecutionAttributes (where it's already stored via .withOperationName()), removing the need for per-operation lambdas.
• Added resolve(SdkRequest, ExecutionAttributes) as a default method on AuthSchemeOptionsResolver, preserving the existing 1-arg resolve(SdkRequest) as the abstract method for binary compatibility with service modules compiled against 2.47.0+. The default delegates to the 1-arg method, so old service modules paired with new core do not hit AbstractMethodError.
• Generated clients now use a shared anonymous class field (authSchemeOptionsResolver, endpointResolver) that overrides the 2-arg method. This avoids per-operation lambda allocations while keeping zero constant pool cost per operation.
• Updated resolveAuthSchemeOptions to read all inputs (auth scheme provider, region, SigV4a region set, endpoint provider) from executionAttributes instead of clientConfiguration, ensuring request-level plugin overrides are respected.
• Removed the factory methods (authSchemeResolver, endpointResolver) from generated clients — no longer needed.
• Removed @FunctionalInterface from EndpointResolver to allow future interface evolution.
• No japicmp exclusion needed — the interface change is binary-compatible (new default method added, existing abstract method unchanged).

Testing

• Updated AuthSchemeResolutionStageTest and GeneratePreSignUrlInterceptorTest (EC2) to match the new interface.
• Updated all codegen fixture files (24 files) to reflect the new generated output.
• Added AuthSchemeProviderOverrideTest (S3) to verify request-level plugin overrides for auth scheme provider and region are respected.
• Added OldAuthSchemeOptionsResolverCompatibilityTest in old-client-version-compatibility-test using Polly 2.48.0 to verify no AbstractMethodError in mixed-version scenarios (new core + old service module).
• Verified EndpointOverrideConfigurationTest passes — confirms per-request endpoint provider overrides still work correctly.
• Full CI build passes (codegen tests, sdk-core unit tests, service compilation, integration tests).

Screenshots (if appropriate)

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)

Checklist

• I have read the CONTRIBUTING document
• Local run of mvn install succeeds
• My code follows the code style of this project
• My change requires a change to the Javadoc documentation
• I have updated the Javadoc documentation accordingly
• I have added tests to cover my changes
• All new and existing tests passed
• I have added a changelog entry. Adding a new entry must be accomplished by running the scripts/new-change script and following the instructions. Commit the new file created by the script in .changes/next-release with your changes.
• My change is to implement 1.11 parity feature and I have updated LaunchChangelog

License

• I confirm that this pull request can be released under the Apache 2 license