Add support for block derivatives

Does not look like this is too tricky, except for the FullyValidatable requirement, which is not defined for almost any block in 10.x.

Menus and views blocks are available in the UI, menus have some basic test coverage.

Any clues as to where max-age 1 instead of -1 is coming from are welcome, so far I've been unable to track it down.

I've spent several hours figuring what's going on here with max-age, writing this up quickly so I don't forget where I am.

This only happens from inside the test runner, I can't reproduce it from outside with cache debugging headers turned on.

The culprit is the views_block:content_recent-block_1 block plugin. Deep inside Views, $view->element['#cache']['max-age'] gets changed from -1 to 1, seemingly in StylePluginBase::renderFields() here:

          // Views may be rendered both inside and outside a render context:
          // - HTML views are rendered inside a render context: then we want to
          //   use ::render(), so that attachments and cacheability are bubbled.
          // - non-HTML views are rendered outside a render context: then we
          //   want to use ::renderInIsolation(), so that no bubbling happens
          if ($renderer->hasRenderContext()) {
            $renderer->render($data);
          }
          else {
            $renderer->renderInIsolation($data);
          }

Because we mess with render contexts ourselves in the ApiComponentsController, I am guessing something goes wrong here with bubbling the cache metadata.

Next up: investigate what happens inside the renderer when this happens to see why max-age gets set to 1.

Finally tracked it down. @Wim unfortunately you lost that bet!

It's the changed field that is rendered in the Recent Content block. This uses the timestamp_ago formatter. In the test, the recent content was only just created, so the timestamp only displays "X seconds ago", and in turn the max-age of the field is set to 1 second in DateFormatter::formatDiff():

          case 's':
            $max_age = min($max_age, 1);
            break;

The max-age then bubbles all the way up to the components API response.

The reason I couldn't reproduce this the same way outside of the test is that my recent content is not quite so recent! There is a fallback in ApiComponentsController:

    // Even if one or more of the component previews is technically not
    // cacheable, cache it anyway for up to 1 minute, precisely because it is
    // just a preview.
    if ($cacheability->getCacheMaxAge() === 0) {
      $cacheability->setCacheMaxAge(60);
    }

So the fix would be to adjust this to set it to 60 if it's less than 60 (but not permanent/-1), instead of only if it's 0. We probably want to consider setting it a bit higher even, if the previews are 5 minutes or maybe even 1 hour out of date it doesn't matter here. We have cache tags anyway if something changes!

Also discovered while working on this: blocks can vary, including per-user. For example, you can have a Views block with contextual filter that defaults to the current user. This means that the previews effectively become uncacheable, if the user cache context is bubbled up to the response. If we ignore this, we risk leaking information about the user that happened to store the cache to other users.

For now, I've worked around this by explicitly switching to the anonymous user during rendering and then ignoring any user-related cache contexts. But this is probably not a long term solution; we should decide what is acceptable here. Maybe a better answer is to cache each preview separately, then we can vary per-user blocks without having to re-render static components.

Added some additional comments and a todo linking to the repurposed #3484666: Show configuration forms for Block components

I've merged in #3485917: `ComponentTreeMeetRequirements` constraint validator must be updated now that Blocks-as-Components are supported + make PageTemplate render main content! and closed #3486409: Decide how to handle block previews per user as that's implemented here now.

Simplified the use of match() and shortened some of the rest of the code, this is ready to go now for me.