HTTP API: new /xb/api/entity-form/{entity_type}/{entity}/{entity_form_mode} route to load form for editing entity fields (meta + non-meta)

Overview

Quoting #3454094: Milestone 0.1.0: Experience Builder Demo:

8. As a content creator, I want to edit meta fields directly within the page builder interface. For example, the menu links and URL alias should be editable on the same page as the page builder.

(Saving these is out of scope — because it is out of scope for #3450586: [META] Back-end Kanban issue tracker too.)

Proposed resolution

1. Route definition:
   

   experience_builder.api.entity_form:
     path: '/xb/api/entity-form/{entity_type}/{entity}/{entity_form_mode}'
     defaults:
       _form: '\Drupal\experience_builder\Form\EntityForm'
       _title: 'Entity Form'
     requirements:
       _permission: 'access administration pages'
     options:
       parameters:
         entity:
           type: entity:{entity_type}
   

2. Retrieve $form['meta'] (see NodeForm) — more scalable solution to follow in #3463991: [RESEARCH] How to identify all meta fields for an arbitrary content entity?

   Per @lauriii in #6: use the route's "form mode" parameter, to load the appropriate form. The intent: start with the default node edit form, but allow defining a separate form mode + EntityFormDisplay for a more tailored UX. @lauriii expressed explicitly the desire for this parametrization, to allow not needing to redo this in the future.

   (Stepping through how /node/1/edit works, it's \Drupal\Core\Entity\Enhancer\EntityRouteEnhancer + \Drupal\Core\Entity\Entity\EntityFormDisplay::collectRenderDisplay() that do the crucial pieces. But note how \Drupal\Core\Entity\Enhancer\EntityRouteEnhancer::enhanceEntityView() does have an explicit mention of $defaults['view_mode'] = $view_mode;, but \Drupal\Core\Entity\Enhancer\EntityRouteEnhancer::enhanceEntityForm() has no equivalent!)

3. Explicit high-level test coverage for verifying this route returns form markup (BrowserTestBase, Cypress E2E test is impossible in this issue).
4. Don't worry about CSS/JS assets for now: getting the form to load at all is the goal (there are other issues in progress that improve the asset loading parts).
5. The expected request body should be documented in /openapi.yml.

User interface changes

None — we'll need a front-end sibling issue to actually use this. This is about allowing that front-end work to happen independently, about pre-emptively unblocking that.