add default widgets to an area

[ETLaurent]

Summary

Summarize the changes briefly, including which issue/ticket this resolves. If it closes an existing Github issue, include "Closes #[issue number]"

What are the specific steps to test this change?

For example:

1. Run the website and log in as an admin
2. Open a piece manager modal and select several pieces
3. Click the "Archive" button on the top left of the manager and confirm that it should proceed
4. Check that all pieces have been archived properly

What kind of change does this PR introduce?

(Check at least one)

• Bug fix
• New feature
• Refactor
• Documentation
• Build-related changes
• Other

Make sure the PR fulfills these requirements:

• It includes a) the existing issue ID being resolved, b) a convincing reason for adding this feature, or c) a clear description of the bug it resolves
• The changelog is updated
• Related documentation has been updated
• Related tests have been updated

If adding a new feature without an already open issue, it's best to open a feature request issue first and wait for approval before working on it.

Other information:

[linear]

PRO-3133 As a developer I can assign a "def" property for an area field

Defaults for a subfield of type area are specified as an array value for the def property. They may also contain nested areas in the same format, etc. Implementation of this may require new logic recursively exploring schemas etc. Such logic may be required on both front and back end. Reuse of existing similar logic is strongly encouraged.

The sanitize method for array fields on the server side already supports array values, however at the time an area is instantiated on the front end async work is not possible, nor is it necessary for the kinds of values that make sense in a hardcoded default.

Area-specific defaults for subareas

To further clarify, area-specific defaults must be recursively supported for subareas as shown below:

body: {
  type: 'area',
  options: {
    widgets: {
      // Has sub-areas
      'columns': {}
    }
  },
  def: [
    {
      type: 'columns',
      n: 3,
      // A field of type area withcin the columns-widget module
      column1: [
        {
          type: '@apostrophecms/rich-text',
          content: '<h3>Column 1 Begins</h3>'
        }
      ]
    }
  ]
}

Overriding placeholders of a nested area is not supported as it is difficult to picture a use case and it would be very difficult to pass them through nested Vue apps.

Convenience syntax: widget name only

If an entry in the array consists of a string, it should be treated as { type: 'string here' }.

Acceptance criteria

• testbed project contains at least one area field with a def property containing an array of widgets, including nested areas.
• At least one of these must specify type and other property values.
• At least one of these must just be a widget type name (a string).
• More than one of the same widget type must be present.
• This behaves as expected when the area is instantiated (all of the widgets called for are populated in the area by default).

[boutell]

I'm closing this PR because it does not appear to be actionable. It can be reopened if we elect to return to this topic.