Rework thread management.

High level changes:

• introduce simple SmartExecutor to hide underlying things; offer minimal surface just enough for consumers
• make 3 consumers use them with try-with-resources consistently (basic connector, metadata resolver, BF collector)
• on Java 21 use virtual threads, as all 3 consumer executes very IO bound tasks (ideal contenders)

Details:

• consumer basic connector logic simplified; instead of going directly for "direct" executor, use one single method, and perform direct executions as needed (as it had already all in place already); basic connector retains the ability to "direct execute" tasks when appropriate (as it knows ahead the task count)
• all 3 consumers use session cached SmartExecutor instances (basic connector exceptions for direct execution explained above)

Consequences: the parameters

• for basic connector: aether.connector.basic.downstreamThreads, aether.connector.basic.upstreamThreads and aether.connector.basic.threads (they may be suffixed with .repoId)
• for BF collector aether.dependencyCollector.bf.threads
• for metadata resolver aether.metadataResolver.threads

are from now on global and reflect the reality for maven session, in a way they are now truly aplied per-Maven session (limits now represent true per-session limits).

Before, this was not the case, and Maven was able to fully "step over" these limits: consider BF collector, it created always "local" thread pool with size 5. But alas, Maven 4 builds project models already in parallel (!), hence, BF collector (to resolve models for model builder) was already called from several threads, and each thread created "local" pool for it's own use.

This may imply that pool sizes may need a revisit, as they may be too conservative now (or they were just not truly applied, as intended).

Fixes #1537