Fix ReflectionTypeLoadException for ILambdaResponseStream when bundli…

[jonathanbcsouza]

Issue #, if available:
#2430

Description of changes:

The dotnet:8.v88 managed runtime ships Amazon.Lambda.RuntimeSupport 2.1.1.0 which contains ImplLambdaResponseStream : ILambdaResponseStream in ResponseStreamLambdaCoreInitializerIsolated.cs. When a function bundles Amazon.Lambda.Core < 3.0.0 (which dotnet publish does by default), the older DLL in /var/task takes assembly resolution precedence over the runtime's copy in /var/runtime. Any code calling GetTypes() on the RuntimeSupport assembly triggers ReflectionTypeLoadException because .NET cannot resolve ILambdaResponseStream from the loaded older Core.

This breaks all .NET 8 Zip Lambda functions on Auto runtime management that use ASP.NET Core hosting, AutoMapper, MediatR, or any DI framework that scans types at startup. May also affect dotnet:10.v36 and any any .NET managed runtime that shipped the response streaming RuntimeSupport.

Fix: Replace the direct ILambdaResponseStream interface implementation (ImplLambdaResponseStream) with a DispatchProxy-based dynamic implementation. No type in the RuntimeSupport assembly directly references ILambdaResponseStream at compile time, so GetTypes() no longer triggers the type load. The proxy is only created at runtime after confirming the interface exists in the loaded Amazon.Lambda.Core.

Changes:

• ResponseStreamLambdaCoreInitializerIsolated.cs: Removed ImplLambdaResponseStream nested class. Added reflection-based initialization with DispatchProxy to dynamically implement ILambdaResponseStream without a static type reference.
• ResponseStreamProxy: New DispatchProxy subclass that forwards interface calls to ResponseStream.
• TestImplLambdaResponseStream.cs: Test-only helper replacing the removed production class in unit tests.
• LambdaResponseStreamingCoreTests.cs: Updated to use TestImplLambdaResponseStream.

Testing:

• 284/286 unit tests pass locally (2 failures are NativeAOTTests requiring .NET 9/10 SDK, unrelated to this change)
• Reproduced the original issue and confirmed the fix concept in a test account
• End-to-end response streaming via DispatchProxy not verified locally (requires deploying to /var/runtime/ which is immutable outside the Lambda team's build pipeline)