Add linting rule to validate BPMN class references against Spring configuration beans

[khalilmalla95]

Context / Problem

In DSF, Camunda does not instantiate delegate/listener classes directly. Resolution happens through Spring-managed beans provided by plugin configurations.

A frequent runtime failure occurs when BPMN camunda:class references are not resolvable from the plugin’s registered Spring context. This can lead to errors such as BeanCreationException or class resolution failures during deployment/runtime.

The linter should detect these wiring problems early.

Goal

Validate that all relevant BPMN class references are resolvable via Spring beans from configurations registered by the plugin definition.

Scope

This rule validates:

1. Spring configuration classes returned by ProcessPluginDefinition#getSpringConfigurations()
2. BPMN camunda:class references (delegates/listeners)
3. Bean coverage based on @Bean method return types in registered Spring configurations

Validation Logic

1. Load the plugin definition (ProcessPluginDefinition) via existing linter/plugin adapter flow.
2. Invoke getSpringConfigurations() and collect all returned configuration classes.
3. Scan BPMN files for relevant camunda:class usages (e.g., service/send tasks, execution listeners, task listeners, message-related usages where applicable).
4. For each registered configuration class, inspect methods annotated with @Bean and collect their return types as available bean types.
5. Cross-check BPMN-referenced classes against the available bean types (including assignable type compatibility if applicable).
6. Report unresolved references.

Expected Linter Output

• ERROR: If a BPMN-referenced class is not provided by any bean from the registered spring configurations.
• SUCCESS: If all relevant BPMN references are resolvable (or no relevant references exist).