Split `PagePartialBlock` into component to group content and component to reuse content

[jurgenbelien]

The current PagePartialBlock does two things:

• It makes it possible to reuse content across a site via a Page Partial
• It makes it possible to render content with grouping, ie. Tabs, Accordion, etc.

Currently, this means that, to easily group content, it has to be grouped inside a PagePartial, which might overload the PagePartial collection.

Solution

• Create a block called GroupingBlock*. A GroupingBlock has items (Modular Content Multiple Blocks of type GroupingBlockItem) and a layout (String, one of tabs, accordion, etc... The options are those now found in PagePartialBlock)
• Create a block called GroupingBlockItem with title and blocks (Modular Content Multiple Blocks).
• Update PagePartialBlock to remove the layout, and change items to partial (Single Link).

*) I'm open to other names.

[jbmoelker]

Suggestion: Create a separate TabsBlock and AccordionBlock as that's what editors best understand. The PagePartialBlock can keep doing what it does, a part of a page that can be reused on multiple pages.

[jurgenbelien]

While I agree that having the layout in the name is more accessible to content editors, I think we should still stick to the GroupingItem to collect all allowed blocks and get a first version with a GroupingBlock that follows the logic of the PagePartial groupings.

Drawbacks to having the model and explicit layout married to each other are:

1. Not easy to try out different layouts, which hampers experimentation.
2. More migrations that touch the bodyBlocks whenever you introduce a new layout, instead of a simple upgrade of a field of an existing block.
3. More updates to all fragments that contain blocks.
4. Bigger GraphQL queries.