Issue #3613299: Add a VariableProvider plugin type and a variables task type

Adds the seam for computing process variables from the run itself, at the point in the model that asks for them.

What it adds

• A VariableProvider plugin type: Plugin/VariableProvider directory, #[VariableProvider] attribute (id, label, description, provides), VariableProviderInterface, VariableProviderBase and a manager. A provider returns variables for a run and writes nothing itself.
• A variables task type in core: it runs the providers a node selects, writes what they return and advances. Settings are the provider list and the scope to write at, instance or token.
• orchestra.node_setting.providers in the config schema, docs page, nav entry and an extending.md row, French translations.

Behaviour worth reviewing

• The node lists its providers in the order they run, and that stored list is the single source of truth. Where two providers write the same variable, the model shows which one wins.
• Every provider is asked before anything is written, so a provider that throws leaves the instance untouched instead of half-updated, and the step dead-letters whole.
• A selected provider whose plugin has gone (module uninstalled) is logged and skipped rather than being fatal, so an uninstall cannot strand a running process. The editor still shows it as a row marked missing, so it can be removed.
• Returning an empty array leaves the variable absent, which is how a provider says the run is not its case.

The editor

The provider selection is edited as a drag-to-reorder table of the providers the step runs, each row naming the variables it declares and carrying a remove checkbox, with a select and an Add button below for the providers not yet on the step. The table holds the step's own providers only, so the form does not grow with the number installed. The Add button carries the settings-trigger flag the action task uses, so a host that supports it re-renders the table without a save; the table also follows live input, so the addition shows either way and nothing is stored until the save. Reordering rewrites the stored list, so the run order is what the table shows. The list is stored as flat JSON so a modeler round-trip cannot lose it.

One deviation from the issue summary

The method is variables(TokenInterface $token, ProcessInstanceInterface $instance), argument order matching TaskTypeInterface::execute() rather than the order written in the issue.

Per-provider settings are not rendered in this iteration; providers are configurable plugins, so that can be added without changing the type.

Tests

Twelve kernel tests plus a hidden test module with four providers: the listed order deciding the winner (the same pair on two workflows in opposite orders, opposite winners), the drag order and the remove flag being stored, the add select appending, the table following a live addition before any save, the table holding only the step's own providers, a missing provider still being offered for removal, an abstaining provider leaving its variable unset, an unselected provider never running, an unknown ID skipped at runtime, token scope staying local to the branch, and a failing provider writing nothing while raising one incident. The two task-type discovery assertions (engine primitives, modeler palette) are updated for the new element.

Consumer follow-up: https://www.drupal.org/project/yoyaku/issues/3613300