Add API to Manually Register Step Classes

[Zim-Inn]

🤔 What's the problem you're trying to solve?

When running Cucumber-JVM under GraalVM Native Image, the default glue discovery mechanism fails because it relies on classpath scanning.
Native Image does not support directory traversal or dynamic classpath scanning, which results in all step definitions being reported as undefined. Even if the classes are preserved via reflect-config.json, Cucumber still cannot discover them unless a package path is provided to --glue.
However, --glue only accepts package names, not explicit class names, so there is no way to bypass scanning and directly register known step classes. This makes it very difficult to run Cucumber tests in environments where reflection and scanning are restricted.

✨ What's your proposed solution?

Introduce an API or configuration option that allows users to manually register step definition classes with the Cucumber runtime, without relying on package scanning. For example, a new CLI option or programmatic API such as:

CucumberRuntime runtime = CucumberRuntime.builder()
    .addGlueClass(CommonSteps.class)
    .addGlueClass(SqlSteps.class)
    .addGlueClass(ExternalApiSteps.class)
    .build();

or a CLI flag like:

--glue-class jiuli.glue.steps.CommonSteps --glue-class jiuli.glue.steps.SqlSteps

This would let users explicitly list all step classes they want to include, ensuring compatibility with GraalVM Native Image and other restricted environments. It would also reduce reliance on fragile package scanning and make step registration more predictable.

⛏ Have you considered any alternatives or workarounds?

Impl a owned Backend and replace cucumber's JavaBackend.
It is not good to CI.

📚 Any additional context?

No response