Support Spring Framework 7 (Spring Boot 4) and Spring Cloud Gateway 5.x (#826)

* Support Spring Framework 7 (Spring Boot 4) and Spring Cloud Gateway 5.x

Spring Framework 7.0 dropped the MultiValueMap contract from HttpHeaders
(spring-projects/spring-framework gh-33913), removing List get(Object). The
webflux-6.x plugin was compiled against that overload, so every request through
DispatcherHandler#handle threw NoSuchMethodError before the entry span was
created: the service kept serving traffic but produced no traces at all.
spring-cloud-gateway-4.x shades a byte-identical copy of that interceptor and
its witness class still resolves on Spring Cloud Gateway 5.x, so gateway users
hit it through the documented plugin as well.

A bytecode sweep of every built plugin jar, resolving all org/springframework
constant-pool refs against spring-web/webflux 5.3.39, 6.2.0 and 7.0.5, found
only two Spring 7 removals reaching the agent, across three call sites.

- spring-webflux-6.x / -5.x: read the header via HttpHeaders#getFirst(String),
  which is declared on HttpHeaders itself in Spring 5, 6 and 7 with the same
  descriptor. Note HttpHeaders#get(String) does NOT work: compiled against
  Spring 6 javac still emits the (Object) descriptor. getOrEmpty is not
  cross-version safe either, its descriptor changes between 6 and 7.
- mvc-annotation-commons RequestUtil: use getValuesAsList(String). getFirst is
  wrong here because this site consumes every value. Note it additionally
  splits comma-delimited values.
- mvc-annotation-commons AbstractMethodInterceptor: drop the premature reactive
  status read. ServerHttpResponse#getRawStatusCode() was removed in Spring 7,
  and it ran before the response was written so it normally read null anyway.
  The version-specific InvokeInterceptor already sets http.status_code in
  Mono#doFinally, once the status is actually known.

Add Spring generation witnesses to both webflux plugins. The only guard was
WitnessMethod(Mono, contextWrite), which bounds Reactor and not Spring, which
is why the plugin attached to Spring 7 and then failed on every request rather
than cleanly not attaching. On Reactor 3.4 both Mono#subscriberContext and
Mono#contextWrite exist, so the 5.x and 6.x plugins would both match
DispatcherHandler#handle on Spring Boot 2.4-2.7.

Split the WebFlux application toolkit. Reactor removed Signal#getContext() in
3.5.0 and ContextView does not exist before 3.4.0, so no single artifact can
serve both; continueTracing has been broken on all of Spring Boot 3 and 4 since
Nov 2022. apm-toolkit-webflux becomes apm-toolkit-webflux-5.x (package
...toolkit.webflux.v5, unchanged behaviour) and a new apm-toolkit-webflux-6.x
(package ...toolkit.webflux.v6) compiles against Reactor 3.5 and uses
Signal#getContextView(). Compiling forward is deliberate: the module rotted
silently for three years because it compiled against the oldest Reactor, so
javac never flagged the removal. Distinct packages make picking the wrong
artifact a compile error rather than a runtime NoSuchMethodError. The
activation keeps matching the legacy un-versioned names, so applications that
never upgrade their toolkit still work against a newer agent.

No plugin, framework version or Reactor version loses support.

Add webflux-6.x-7.x-scenario (Spring Boot 3.0 -> 4.1, one version per minor)
and gateway-5.x-scenario (Spring Cloud Gateway 5.0.3 on Spring Boot 4). Both
drive a full round-trip so the cross-process ref is asserted, which is the only
thing that proves the sw8 header is read back correctly.

Closes apache/skywalking#14047