Split the overloaded result vocabulary into the outcome and the completion payload

Since #3613700: Record a work item's completer and completion time, rename its result field to outcome, and ship the personal task views the work item stores its decision as outcome, but the surrounding vocabulary still calls two different things a result, even though the code otherwise keeps them apart carefully.

The outcome is the resolved decision an outgoing flow condition routes on. The payload is whatever complete() was called with: either a scalar, which is the outcome itself, or an array carrying the outcome alongside a task type's extra data, as a comment task does. OutcomeSignaler takes the second and produces the first, and ResultVariablesInterface's own documentation already draws the distinction.

Proposed renames, by concept:

• The payload key naming the outcome, already centralized as OutcomeResult::OUTCOME_KEY with its value still result: flip the value to outcome.
• timeout_result and default_timeout_result do name an outcome, so timeout_outcome and default_timeout_outcome.
• result_variable does not hold the outcome. It stores the whole payload, which is why a flow condition has to unwrap a member out of it, so it becomes payload_variable rather than anything with outcome in the name.
• result_scope scopes every completion variable, the completer included, so completion_scope.
• ResultVariablesInterface::resultVariables() is payload-shaped, so CompletionVariablesInterface::completionVariables(). It is an api interface with several implementers, so the interface and every implementer move in one commit.
• The ECA resume action and the webform interaction handler each carry a plugin configuration key named result holding an outcome value.

What makes this more than a rename:

• Flipping the payload key rewrites stored data. A payload written to a node's payload variable keeps its shape, so existing process variables hold the old key and both the flow condition and the join coordinator read it back out of them. Those rows need rewriting.
• The same key is the outcome query parameter on an act link, so links already sent stop carrying an outcome.
• The node settings keys are persisted config: the config schema, shipped example workflows, the modeler settings forms and any site's saved workflows.
• Roughly half the occurrences of the word mean payload, so a mechanical find and replace would merge the two concepts rather than separate them. Every site has to be read.

Pre-release, so no update hooks: the data and config rewrites are done by hand.