Support beans configuration in YAML and XML DSL

[christophd]

Description

The citrus-groovy module already supports defining custom beans in the Citrus bean registry via configuration scripts (see run-groovy.adoc):

configuration {
    beans {
        bean('foo', org.example.foo.FooBean.class)
        fooClient = new org.example.foo.FooClientBuilder().build()
    }
}

This is a powerful mechanism for test-level bean registration, but it requires the citrus-groovy dependency. Users working exclusively with the YAML or XML DSL should be able to define beans in the same way — without pulling in a Groovy dependency.

The YAML and XML DSL test definitions already support a top-level endpoints section (see YamlTestCase.java / XmlTestCase.java) for registering endpoints. A similar beans section should be added that allows users to specify bean class types, names, and properties. These beans would be instantiated and registered in the Citrus bean registry (ReferenceResolver) at test startup, making them available for injection into test actions and other components.

Proposed YAML syntax

name: MyTestIT
beans:
  - name: myValidator
    type: org.citrusframework.validation.DefaultTextEqualsMessageValidator
  - name: connectionFactory
    type: org.example.jms.ActiveMQConnectionFactory
    properties:
      brokerUrl: "tcp://localhost:61616"
      userName: "admin"
endpoints:
  ...
actions:
  ...

Proposed XML syntax

<test name="MyTestIT">
  <beans>
    <bean name="myValidator" type="org.citrusframework.validation.DefaultTextEqualsMessageValidator"/>
    <bean name="connectionFactory" type="org.example.jms.ActiveMQConnectionFactory">
      <property name="brokerUrl" value="tcp://localhost:61616"/>
      <property name="userName" value="admin"/>
    </bean>
  </beans>
  <endpoints>
    ...
  </endpoints>
  <actions>
    ...
  </actions>
</test>

Expected Behavior

• A beans section is supported at the top level of YAML and XML test definitions (alongside endpoints and variables)
• Each bean entry specifies a name, type (fully qualified class name), and optional properties (key-value map)
• Beans are instantiated via default constructor and properties set via setter methods
• Beans are registered in the Citrus bean registry before test actions execute
• No dependency on citrus-groovy is required

Additional Context

• The ReferenceResolver abstraction already supports programmatic bean binding — the YAML/XML parsers just need to call bind(name, instance) after instantiation
• The endpoints section in YamlTestCase and XmlTestCase provides a close architectural pattern to follow
• This would make pure YAML/XML test definitions more self-contained and reduce the need for external Spring or Groovy configuration

[lordrip]

Related Camel implementation https://issues.apache.org/jira/browse/CAMEL-18189