[WHIT-2788] Configurable document form objects WIP

[ChrisBAshton]

What

WIP: exploring what it would look like to do the entire refactor in one PR, as opposed to PR 10965 which explores rolling it out in stages.

This PR refactors the schema design for config-driven document types by separating concerns that were previously conflated under edit_screens. We now:

• removed settings.edit_screens, in favour of a new top-level forms hash. It describes things at the UI level: which fields appear on which forms.
• adds new top-level presenters field, describing which field values get sent to Publishing API (and how to map them)
• removes schema.properties in favour of schema.attributes: effectively a slimmed down version of the former.
• schema.validations remains unchanged, but we no longer have 'nested' validation (e.g. schema.properties.duration.validations) - the 'nested' validation has moved up into the schema.validations (in this example, schema.validations.duration). This isn't represented in the overview below as we only had one example and it's more of a side-effect than a deliberate change.

Overview of schema changes:

"schema": {
-  "properties": {
-    "body": {
-      "title": "Body",
-      "type": "string",
-      "format": "govspeak"
-    }
+  "attributes": {
+    "body": {
+      "type": "string",
+    }
+  }
}
+ "forms": {
+  "documents": {
+    "fields": {
+      "body": {
+        "title": "Body",
+        "description": "The main content of the page",
+        "block": "govspeak"
+      }
+    }
+  }
+ },
+ "presenters": {
+   "publishing_api": {
+    "body": "govspeak"
+  }
+}
"settings": {
-  "edit_screens": {
-   "document": ["body"]
- }

Why

Bunching up properties into 'edit screens' was a good first step in #10786, allowing us to update different block content fields in isolation on separate tabs. But it was too restrictive: we had no way of denoting which fields should be 'grouped' (e.g. start & end date fields for an overall 'duration') and also we were having to wrestle with wanting to present the fields in one way but present them differently when presenting to Publishing API. The previous properties and edit_screens concepts were conflating too much.

The refactoring of the schemas we've done here should make it quicker and easier to iterate document types in future.

Jira: https://gov-uk.atlassian.net/browse/WHIT-2788

---

⚠️ This repo is Continuously Deployed: make sure you follow the guidance ⚠️

This application is owned by the Whitehall Experience team. Please let us know in #govuk-whitehall-experience-tech when you raise any PRs.

Follow these steps if you are doing a Rails upgrade.

[ChrisBAshton]

I was thinking about this yesterday - even though we only have flattened top level properties now, we need to make sure that the values are retained, even if the values are nested structures. So make sure we have a test for something like

"foo" => { "bar" => { "baz" => 123 } }