Move the workflow variable providers to Orchestra's VariableProvider plugin type

Follow-up consumer change for the Orchestra plugin type added in #3613299: Add a VariableProvider plugin type and a variables task type. Blocked on it.

yoyaku_orchestra currently carries its own variable seam: WorkflowVariableProviderInterface, WorkflowVariableProducer, the yoyaku_orchestra.workflow_variable_provider tag and the yoyaku_prepare_workflow_variables action. Five providers use it: settlement, auto-confirm and arrival in yoyaku_orchestra, cancellation in yoyaku_orchestra_order, deposit in yoyaku_payment_orchestra.

Once Orchestra ships the generic plugin type, all four of those classes go away and the providers become Plugin/VariableProvider plugins. A YoyakuVariableProviderBase in yoyaku_orchestra resolves the order from the instance once, memoized, and delegates to the existing variablesFor() signature, so the provider bodies are unchanged.

Consequences to accept

Ordering comes from the step's configured list instead of the order of tags in services.yml, which makes it visible in the model.

A submodule install no longer contributes its variable on its own: the step has to list the plugin. The model already contains the fork that branches on the variable, so it was already coupled to the submodule; this only makes the other half of that coupling explicit. No "empty list means all" fallback, that would reintroduce the invisible mode.

The prepare node in the shipped BPMN models retypes from action to variables, hand-patched on live. Pre-1.0, so no update hook.

Gotcha

The providers become ContainerFactoryPluginInterface plugins, so injected services must be protected, not private readonly, or DependencySerialization breaks them.

Scope

Plugin conversion, base class, removal of the local seam, test updates, docs and French translations.