Fix a task's nested plugin-settings subform breaking the BPMN.io modeler save

A task type that embeds another plugin's configuration as a nested subform (the settle and payment tasks embed a payable resolver through PayableResolverConfigTrait) makes the BPMN.io modeler fail to save the whole model, with the error "The subform is not contained by the given parent form."

Cause: the resolver settings subform takes its #parents from the parent form at build time. The Modeler API builds a task's configuration form outside a request to validate it on save, so the parent form has no #parents then and the subform bakes a parents path that misses the parent's prefix. At submit the nested SubformState no longer sits under the parent form and throws.

Fix: drop that build-time #parents on the resolver settings subform and let the Form API derive it from the element's position in the tree, the way the interaction settings subform already does. This form is always rendered through the Form API (the Complete modeler, or the Modeler API's save-time validation), so nothing relies on the baked value.

Adds a kernel test asserting the resolver settings subform carries no baked #parents, and documents the pitfall for task-type authors in the modeling guide.