Use this as the commit message if GitHub squash-merges this PR (paste into the squash commit message box):

Modularize the HTTP transport layer into independent Jetty 9, Jetty 12, servlet, and HttpService bundles, and add a jakarta.servlet/OSGi Whiteboard bridge

Core no longer bundles a transport implementation, servlet support, or an OSGi
HttpService/Whiteboard bridge. Six new/changed bundles take over:

- org.jupnp.transport.jetty9: the existing Jetty 9.4 transport, moved out of
  core unchanged.
- org.jupnp.transport.jetty12 (new, optional): a Jetty 12 transport for Java
  17+, built on Jetty's servlet-free core API, with its own standalone
  StreamServer -- it opens its own port unless a SharedStreamServerProvider
  is also installed (see below).
- org.jupnp.transport.javax.servlet (new): the generic javax.servlet transport
  infrastructure (ServletStreamServerImpl, ServletContainerAdapter, the
  blocking/async servlet variants), shared by jetty9 and Android, neither of
  which is Jetty- or Android-specific about it.
- org.jupnp.transport.javax.httpservice (new, optional): the classic OSGi
  HttpService bridge, registered behind a new generic
  SharedStreamServerProvider SPI so core has no compile-time dependency on
  javax.servlet or the HttpService API at all, in any form.
- org.jupnp.transport.jakarta.servlet (new, optional): a jakarta.servlet 6.1
  port of org.jupnp.transport.javax.servlet, async-only -- jakarta.servlet has
  mandated async support since 5.0, so no blocking/detection fallback is
  needed.
- org.jupnp.transport.jakarta.whiteboard (new, optional): the jakarta.servlet
  counterpart of org.jupnp.transport.javax.httpservice, bridging to the OSGi HTTP
  Whiteboard Service for Jakarta Servlet (org.osgi.service.servlet 2.0.0),
  the Whiteboard-based replacement runtimes like Pax Web 10+ use instead of
  the classic HttpService.

Applications must now depend on org.jupnp.transport.jetty9 or
org.jupnp.transport.jetty12 explicitly -- core no longer pulls in a transport
for free, and org.jupnp.bom (a conventional Maven BOM: import it, then declare
exactly the artifacts you want) does not auto-select one either, including
based on build JDK version. Android is already updated to add this
dependency; other consumers will need the same change.

Transport discovery: outside OSGi, both transports register via
java.util.ServiceLoader, the same mechanism core previously used for its
built-in transport; ServiceLoader finding more than one fails fast with a
clear error instead of picking one non-deterministically. In OSGi, transports
and shared-server providers are wired via Declarative Services instead:
OSGiUpnpServiceConfiguration takes each through a reference that collects all
matching services and fails the same way on ambiguity, so discovery doesn't
race bundle start order and doesn't silently pick a bundle when more than one
is present. Port sharing is decided purely by which SharedStreamServerProvider
is bound, independent of which transport bundle supplies the StreamClient.

Dependency updates: Jetty 9 (9.4.53 -> 9.4.58), Pax Web 8.x (8.0.25 ->
8.0.36), Jetty 12 (12.1.10 -> 12.1.12), Pax Web 11.x (11.1.2 -> 11.1.3),
Pax Logging (-> 2.3.5), logback (1.5.35 -> 1.6.2), slf4j (2.0.11 -> 2.0.18).

Project version is set to 4.0.0-SNAPSHOT.

This PR was generated with significant use of AI.

What this does

This started as the transport split requested in #297 (comment) and grew into a full modularization of jUPnP's HTTP layer. Six bundles now do what core used to do internally:

Core (org.jupnp) no longer has any compile-time or OSGi-manifest dependency on javax.servlet, jakarta.servlet, org.osgi.service.http, or org.osgi.service.servlet -- not even an optional one. It talks to transports through TransportConfiguration and to an optional shared HTTP server through a new SharedStreamServerProvider SPI; neither interface mentions servlet or HttpService/Whiteboard types.

Discovery is fail-fast on ambiguity in both the ServiceLoader path (non-OSGi) and the Declarative Services path (OSGi), so a misconfigured classpath/bundle-set with two transport bundles -- or two shared-server providers -- throws a clear error instead of picking one non-deterministically. Which transport to use is always an explicit choice the consumer makes: org.jupnp.bom manages versions for org.jupnp.transport.jetty9 and org.jupnp.transport.jetty12 side by side, but importing it doesn't add either (or any other artifact) as a dependency by itself -- the consumer still declares exactly the one they want. Port sharing (via SharedStreamServerProvider) is a separate, orthogonal choice from which transport is in use -- org.jupnp.transport.jetty12 plus org.jupnp.transport.jakarta.whiteboard shares a port with a Jakarta HTTP Whiteboard runtime (e.g. Pax Web 11+) the same way org.jupnp.transport.jetty9 plus org.jupnp.transport.javax.httpservice shares a port with a classic HttpService.

Along the way, dependencies exercised by the new itests got a pass too: Jetty 9 (9.4.53 -> 9.4.58) and its matching Pax Web 8.x (8.0.25 -> 8.0.36), Jetty 12 (12.1.10 -> 12.1.12) and Pax Web 11.x (11.1.2 -> 11.1.3), Pax Logging (-> 2.3.5), logback (1.5.35 -> 1.6.2), and slf4j (2.0.11 -> 2.0.18).

Compatibility

• Source/binary compatible for consumers going through TransportConfiguration/UpnpServiceConfiguration -- with one exception: subclasses of OSGiUpnpServiceConfiguration. No API changes to StreamServer, StreamClient, Router, or the discovery entry points. OSGiUpnpServiceConfiguration itself moved from manually binding HttpService to Declarative Services, which removes or changes several protected/public extension points a subclass may have relied on: the protected BundleContext context, protected TransportConfiguration transportConfiguration, and protected HttpService httpService fields are gone, as are the activate(BundleContext, Map<String, Object>), setHttpService(HttpService), and unsetHttpService(HttpService) methods (activate(Map<String, Object>), without the BundleContext parameter, replaces the old activate override point). A subclass no longer binds HttpService itself at all -- install org.jupnp.transport.javax.httpservice or org.jupnp.transport.jakarta.whiteboard (steps 3/4 below) instead, and DS injects a SharedStreamServerProvider automatically. See step 6 below.
• Not binary compatible for consumers referencing servlet/HttpService classes directly. Anyone who imported org.jupnp.transport.impl.ServletStreamServerImpl, ServletContainerAdapter, HttpServiceServletContainerAdapter, etc. from org.jupnp will get compile errors -- those classes moved to new packages in the new bundles (see migration steps). This also covers org.jupnp.http.RequestInfo's HttpServletRequest-based methods -- reportRequest, reportParameters, reportHeaders, reportCookies, reportClient, dumpRequestHeaders, dumpRequestString, getRequestInfoString, getRequestFullURL, and the HttpServletRequest-typed overloads of isPS3Request/isJRiverRequest/isXbox360Request/isXbox360AlbumArtRequest -- which moved unchanged to the new org.jupnp.transport.javax.servlet.ServletRequestInfo in org.jupnp.transport.javax.servlet (step 3 below already covers adding that dependency). RequestInfo stays in core with only its String-based overloads (isPS3Request(String, String), isAndroidBubbleUPnPRequest, isJRiverRequest(String), isWMPRequest, isXbox360Request(String, String)) -- nothing was dropped, it was only split by whether it needs javax.servlet.
• OSGi manifests changed. org.jupnp's Import-Package no longer lists javax.servlet, javax.servlet.http, org.osgi.service.http, jakarta.servlet, or org.osgi.service.servlet at all (previously optional for the javax/HttpService ones, now absent everywhere). Runtimes that don't have those packages will now resolve org.jupnp exactly as before (it never needed them to resolve); runtimes that do have them no longer get core wired to them implicitly.
• Jetty 9 implementation classes renamed for symmetry with Jetty 12. org.jupnp.transport.impl.jetty.JettyTransportConfiguration -> org.jupnp.transport.jetty9.Jetty9TransportConfiguration (same package/name change for JettyStreamClientImpl -> Jetty9StreamClientImpl, JettyServletContainer -> Jetty9ServletContainer, and StreamClientConfigurationImpl -> Jetty9StreamClientConfigurationImpl). Only relevant if you referenced these directly (e.g. a custom createStreamClient()/createStreamServer() override, per the docs); consumers going through TransportConfiguration/UpnpServiceConfiguration are unaffected.

Steps for existing consumers of the Jetty 9 implementation

1. org.jupnp.bom is now a conventional Maven BOM (previously a convenience aggregator that pulled in org.jupnp/org.jupnp.osgi/org.jupnp.support transitively). Import it via dependencyManagement/scope=import, then declare exactly the jUPnP artifacts you want as plain dependencies with no <version> (every example below omits it accordingly):

   <dependencyManagement>
     <dependencies>
       <dependency>
         <groupId>org.jupnp</groupId>
         <artifactId>org.jupnp.bom</artifactId>
         <version>...</version>
         <type>pom</type>
         <scope>import</scope>
       </dependency>
     </dependencies>
   </dependencyManagement>
   <dependencies>
     <dependency>
       <groupId>org.jupnp</groupId>
       <artifactId>org.jupnp</artifactId>
     </dependency>
     <dependency>
       <groupId>org.jupnp</groupId>
       <artifactId>org.jupnp.transport.jetty9</artifactId>
     </dependency>
   </dependencies>

   This is the one to not miss: importing the BOM no longer adds org.jupnp core (or a transport) to your classpath by itself -- list every artifact you need explicitly, same as if you weren't using the BOM at all (you can also skip the BOM entirely and pin each artifact's <version> directly, as before). Skipping the transport dependency doesn't break your build, it compiles fine and then fails at runtime with no transport found; skipping org.jupnp itself is a compile error, so that one's harder to miss. Nothing is auto-selected based on your build's JDK version.
2. If you reference servlet transport classes directly (e.g. a custom UpnpServiceConfiguration.createStreamServer() override using ServletStreamServerImpl/ServletContainerAdapter, per the docs), add the new servlet dependency:

   <dependency>
     <groupId>org.jupnp</groupId>
     <artifactId>org.jupnp.transport.javax.servlet</artifactId>
   </dependency>

   and update the import: org.jupnp.transport.impl.ServletStreamServerImpl -> org.jupnp.transport.javax.servlet.ServletStreamServerImpl (same rename for ServletStreamServerConfigurationImpl, ServletContainerAdapter, ServletUpnpStream, ServletConnection).
3. If you rely on the OSGi HttpService port-sharing path (deploying OSGiUpnpServiceConfiguration where a classic HttpService is present and you want jUPnP to share its port), add the new HttpService bridge bundle to your runtime:

   <dependency>
     <groupId>org.jupnp</groupId>
     <artifactId>org.jupnp.transport.javax.httpservice</artifactId>
   </dependency>

   No code changes needed for this path -- it's picked up automatically via Declarative Services once installed. If you don't install it, OSGiUpnpServiceConfiguration activates anyway and falls through to the transport's own native StreamServer on its own port -- unlike before this PR, where a missing HttpService simply meant the component never activated. If that fallback port collides with an already-running server (e.g. openHAB/openhab-addons commonly do, since their web UI's HttpService and jUPnP's default streamListenPort are both 8080), stream server init fails with a BindException and the whole router stays disabled. See openhab/openhab-core#5740 for a worked example of the required consumer-side change.
4. If your runtime uses the OSGi HTTP Whiteboard Service for Jakarta Servlet instead of the classic HttpService (e.g. Pax Web 10+, which dropped HttpService; this is the runtime you'll have if you've migrated to Jetty 12/Jakarta EE 10), use the jakarta bridge instead -- pair it with org.jupnp.transport.jetty12:

   <dependency>
     <groupId>org.jupnp</groupId>
     <artifactId>org.jupnp.transport.jetty12</artifactId>
   </dependency>
   <dependency>
     <groupId>org.jupnp</groupId>
     <artifactId>org.jupnp.transport.jakarta.whiteboard</artifactId>
   </dependency>

   Same activation model as step 3: picked up automatically via Declarative Services once installed, no code changes needed; if not installed, OSGiUpnpServiceConfiguration falls through to jetty12's own standalone port.
5. Android is already updated in this PR (depends on org.jupnp.transport.jetty9 and org.jupnp.transport.javax.servlet); no action needed for AndroidUpnpServiceConfiguration consumers.
6. If you subclass OSGiUpnpServiceConfiguration: drop any override of setHttpService/unsetHttpService/the removed httpService/context fields -- port sharing is now handled entirely by installing a bridge bundle (steps 3/4), with no code on your side. If you overrode activate(BundleContext, Map<String, Object>), override activate(Map<String, Object>) instead (the BundleContext parameter is gone, since this class no longer needs it directly).

This PR was generated with significant use of AI.