FELIX-6859 allow a bounded VirtualThreadPool as the virtual threads executor

Jetty 12 documents a QueuedThreadPool whose virtual threads executor is a
bounded VirtualThreadPool as the preferred setup, but Felix HTTP could not
be configured to build it. The two virtual thread options were the
extremes: an unbounded number of concurrent tasks, or a standalone
VirtualThreadPool that creates only virtual threads. A deployment that
wants platform threads for the acceptors and the selectors, and a bound on
concurrent request tasks, had no way to express that.

Adds org.apache.felix.http.jetty.virtualthreads.max to the jetty12 bundle.
When virtual threads are enabled and this property is set to a positive
value, the thread pool becomes a QueuedThreadPool, sized by threadpool.max
as usual, whose virtual threads executor is a VirtualThreadPool bounded by
setMaxConcurrentTasks. Note that unlike threadpool.max, this property
bounds the number of concurrent tasks rather than the number of threads.

The VirtualThreadPool is added as a bean of the QueuedThreadPool, because
setVirtualThreadsExecutor() only stores the executor and does not manage
its life cycle; an unstarted VirtualThreadPool rejects every task with a
RejectedExecutionException. Being a managed bean also covers the teardown,
so the pool is stopped when the server stops.

Non-positive values fall through to the existing behaviour, since Jetty
itself treats maxConcurrentTasks <= 0 as unbounded. The pre-existing branch
that builds a standalone VirtualThreadPool keeps using threadpool.max as
its bound, so no released behaviour changes.

The thread pool selection is extracted from createServer() into a package
private createThreadPool(JettyConfig), returning null when no thread pool
is configured so that Jetty's own default applies, so that the resulting
pool can be asserted without starting a server. JettyServiceThreadPoolTest
covers every combination: the type of pool, its bound, and that the
VirtualThreadPool is registered as a bean of the QueuedThreadPool.

Two related fixes in the same area:

* The attribute definition for virtualthreads.enable passed -1 as its
  default value, which selects the int constructor of
  AttributeDefinitionImpl, so the flag was declared as an INTEGER
  attribute defaulting to -1 even though JettyConfig reads it with
  getBooleanProperty. It is now declared as a BOOLEAN defaulting to false.
  Reading a previously stored integer value is unaffected.
* The guard in JettyVirtualThreadsIT matched the version string with
  startsWith("21"), so the test body was skipped on every later JDK while
  the test was still reported as passing. It now compares the feature
  version, so the ITs run on Java 21 and on every later JDK. Note that the
  Pax Exam runner swallows a failed assumption and reports the test as
  passing rather than as skipped, so below Java 21 the test still shows up
  as green, as it did before.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>