CAMEL-23147: Embed citrus test plugin in camel-launcher

[gnodet]

Summary

• Refactored the camel-jbang-plugin-test to use proper command classes (TestInit, TestRun) instead of indirect JBang process calls via citrus-jbang-connector
• Replaced the citrus-jbang-connector dependency with citrus-base, which provides all needed Citrus APIs (TestEngine, TestRunConfiguration, CitrusVersion, etc.) without requiring JBang
• Removed the CitrusExecutionStrategy that spawned external JBang processes to run Citrus commands
• Added the test plugin as a pre-installed embedded plugin in camel-launcher
• Included Citrus test templates (yaml, xml, java, groovy, feature) directly in the plugin resources

Test plan

• Verify camel test init MyTest.yaml creates a test file from template in the test subfolder
• Verify camel test run executes Citrus tests directly without spawning JBang processes
• Verify export functionality still works via TestPluginExporter
• Verify the launcher includes the test plugin and camel test --help shows subcommands

[github-actions]

🌟 Thank you for your contribution to the Apache Camel project! 🌟
🤖 CI automation will test this PR automatically.

🐫 Apache Camel Committers, please review the following items:

• First-time contributors require MANUAL approval for the GitHub Actions to run
• You can use the command /component-test (camel-)component-name1 (camel-)component-name2.. to request a test from the test bot although they are normally detected and executed by CI.
• You can label PRs using build-all, build-dependents, skip-tests and test-dependents to fine-tune the checks executed by this PR.
• Build and test logs are available in the summary page. Only Apache Camel committers have access to the summary.

⚠️ Be careful when sharing logs. Review their contents before sharing them publicly.

[gnodet]

Review notes — potential downsides to consider

1. CLI backward compatibility

The old CitrusExecutionStrategy forwarded any command to Citrus JBang. The new approach only exposes init and run as picocli subcommands. Users who relied on other Citrus JBang commands or Citrus-specific flags not re-implemented in TestRun would break or see them silently ignored.

2. Templates bundled & may drift

The Citrus test templates (citrus-yaml.tmpl, citrus-xml.tmpl, etc.) are now embedded in the plugin rather than coming from Citrus JBang. If Citrus upstream updates their templates, ours won't pick up the changes — they'd need manual syncing.

3. Larger launcher footprint

The test plugin was previously excluded from the launcher with the comment "the citrus test plugin cannot be embedded". Now it's pre-installed, pulling citrus-base and its transitive dependencies into the launcher JAR.

4. System property side effects

TestRun.doCall() calls System.setProperty() for user-provided -p properties but never cleans them up. In a long-running process or if the launcher is reused, these properties leak into subsequent operations.

5. Reduced Citrus feature coverage

The old approach delegated entirely to Citrus JBang, so new Citrus features were automatically available. The new in-process TestRun reimplements test resolution and configuration — if Citrus adds new options, they won't be available until we update our code.

6. No test coverage

TestInit and TestRun have no unit tests. Given that TestRun has non-trivial logic (directory scanning, path resolution, configuration building), some test coverage would be valuable.

---

The architectural improvement (in-process vs spawning JBang) is the right direction. It would be good to coordinate with the Citrus project to ensure the in-process API (TestEngine, TestRunConfiguration) is the officially supported integration path.

[davsclaus]

@christophd take a look - this should ideally help and also allow us to embed citrus directly in launcher so its included OOTB, and hopefully also just runs nicely on windows.