Expose the "advanced address" element

I started on this. It looks like we can also support the fallback element named WebformElementWebformAddress which works out of the box (without needing the Address module).

The address elements are so-called "composite" elements which share a lot of similarities to other elements like "Flexbox" and "Fieldset". We can unify these under a shared WebformElementContainerBase interface.

Now that ✨ Move properties on the WebformElement interface Active is in we can remove 1 level of nesting by directly exposing WebformElementMetadata on the child elements rather than exposing WebformElement which has become just a wrapper intended to slim down the schema.

I split off the removal of the nesting level to ✨ Expose the element metadata directly in nested elements Active . I will implement that first because it will simplify this issue.

I have done the first part of the work: I added support for generic composite elements. It looks like there are a few gotchas with composite elements:

The webform module expects the values for the child elements to be passed as parent_element_key[0][child_element_key] but then the validation messages are returned as parent_element_key[items][0][child_element_key]. This is going to be confusing for the GraphQL consumer that there is an unexpected [items] part appearing in the element key.

Another thing I noticed is that when a child element is required, and the composite element is configured to show N number of empty rows, that the validation errors returned by the Webform module are duplicated N times. I am guessing this is intended to make it easier to highlight the validation error in the Drupal rendered webform for the N empty rows. But for the GraphQL consumer this might be confusing since they might get more validation errors back than values they are submitting.

A third thing is that, since we don't know in advance how many child elements are going to be rendered for a composite field that allows multivalue child elements, the Webform module returns element keys like parent_element_key__child_element_key. This will need to be converted into parent_element_key[N][child_element_key] by the frontend implementation. We need to document this somehow.

I think in scope of this issue I am not going to try to transform the internally used logic for handling validation of these elements and just return what we get. Now we have some special cases when handling validation of composite elements, but there will probably be more edge cases in other elements. If this becomes problematic in the future we can implement a plugin system to handle these kinds of edge cases for each Webform element type.

I was too quick in deciding to expose the metadata type directly as children of container / composite elements. It is actually better to expose WebformElement because there can be fields on them that are essential for rendering the forms in the frontend.

A good example is the "maxlength" for text fields. This is exposed on WebformElementTextBase which is an interface for WebformElement.

So I reverted ✨ Expose the element metadata directly in nested elements Active again in this MR.