AsyncAPI 3.x: the problem type

[LautaroPetaccio]

Tenth in the AsyncAPI stack, on top of #1738. Draft: the next two PRs — the sampler, then the fitness with the Guice module — complete it. Until they land, --problemType ASYNCAPI stops with a message saying exactly that, rather than a Guice stack trace.

What is here

• ProblemType.ASYNCAPI, experimental like RPC, WEBFRONTEND and MCP, so nothing changes for anyone who does not ask for it.
• Main: the type is inferred from SutInfoDto.asyncApiProblem when the driver declares one; the algorithm key is resolved over AsyncApiIndividual; the module branch throws the message above.
• docs/options.md regenerated — ConfigToMarkdownTest keeps it honest.

The one decision: EMConfig.usesDriver()

Every other problem type reaches the EM Driver only in white-box mode, or in black-box experiments — and that rule was spelled out as !config.blackBox || config.bbExperiments in five places across Main and Statistics. AsyncAPI breaks it: there is no universal wire to a message-driven service, so the driver holds the broker connection even when the service itself is a black box (see #1738 for why).

Rather than add a third clause to five copies, the rule now lives once, in EMConfig.usesDriver(), and those five places ask it. Behaviour for every existing type is unchanged.

Two sets of guards were deliberately left alone:

• the three in TestSuiteWriter, which decide whether the generated test instantiates a driver. That is a test-writer decision, and the AsyncAPI test writer is a later PR;
• the black-box branches inside the REST, GraphQL and RPC samplers, which are each sampler's own business.

Not here

No @Cfg options yet — nothing so far has needed one. The reply timeout will arrive with the fitness, @Experimental like the rest.

Testing

EMConfigTest gains a test pinning usesDriver(): false for black-box REST, true for black-box AsyncAPI, true for white-box. EMConfigTest + ConfigToMarkdownTest: 111 tests, 0 failures.