Add virtual thread support for SQS message listener containers

[tomazfernandes]

Allow VirtualThreadTaskExecutor to be used as the componentsTaskExecutor by supporting both MessageExecutionThread and virtual-thread execution for user-provided components and listeners.

This preserves the existing hop-back safety mechanism while allowing execution to continue on either MessageExecutionThread or virtual threads on JDK 21+. Reflection is used to detect virtual threads so the JDK 17 baseline remains unchanged.

Also adds SqsPerformanceHarness / SqsPerformanceTests for comparing message-processing throughput under different container configurations. These tests are disabled by default and can be run with -Dperformance=true.

Closes gh-924

SQS Virtual Threads Performance Results

Results from SqsPerformanceTests comparing default (platform threads) vs virtual threads.

Test	Infra	Messages	Concurrent	Load	Throughput (default)	Throughput (VT)	p50 (default)	p50 (VT)
No load	LocalStack	200	10	-	1,786 msg/s	2,439 msg/s	0ms	0ms
1s load	LocalStack	50	10	1s	10 msg/s	10 msg/s	1,003ms	1,002ms
500 concurrent, 1s load	LocalStack	500	500	1s	242 msg/s	242 msg/s	1,001ms	1,001ms
10k concurrent, 1s load	LocalStack	10,000	10,000	1s	-	3,235 msg/s	-	1,000ms
2k concurrent, 2s load	AWS	2,000	2,000	2s	304 msg/s	339 msg/s	2,004ms	2,000ms
10k concurrent, 1s load	AWS	10,000	10,000	1s	-	1,939 msg/s	-	1,000ms
Blocking interceptor (200ms) + 1s load	LocalStack	50	10	1s	-	8 msg/s	-	1,208ms

Key Takeaways

• At low concurrency, virtual threads and platform threads perform similarly in these runs.
• At 2k concurrent against AWS, virtual threads showed about 11% higher throughput with slightly tighter p50 latency.
• 10k concurrent runs completed successfully with virtual threads in this setup.
• Blocking interceptors also worked correctly with virtual threads in these tests.
• In the higher-concurrency AWS runs, the main observed bottleneck was the AWS SDK HTTP connection pool rather than the thread model.