Render blocks later, so they can be placed individually in a region template

Problem/Motivation

Every region template (eg. core/modules/system/templates/region.html.twig) uses {{ content }} to render the blocks in that region. But unlike node templates (eg. core/modules/node/templates/node.html.twig), where you can do things like {{ content|without('field_example') }}, the content of a region cannot be manipulated. This is because the content variable of a region is not an array of renderable elements, but just a string of rendered HTML.

Sometimes you want to be able to have access to the separate blocks, for instance to do something like this:

<div class="grid-container">
    {{ content|without('special-block') }}
  </div>
  {{ content.special-block }}

Proposed resolution

The reason why blocks arrive in the template as an already rendered blob of HTML, can be found in the comments on line 439 and 440 of core/lib/Drupal/Core/Render/Renderer.php:

// If #theme is not implemented or #render_children is set and the element
// has an empty #children attribute, render the children now. [...]

This also points us in the direction of a solution: Build the render array of a region with a #theme property instead of a #theme_wrapper. As far as I can see, this results in the exact same output as the current situation, requiring no changes to twig templates, while adding additional flexibility for those who need it.

Remaining tasks

I did not find any downsides yet, but we have to think of reasons to not do this.
No reasons have been brought forward.

Are there performance implications?
None, except that a little more function nesting (still well within reasonable limits) might theoretically slow down xDebug.

Could caching be a problem when region output is made more dynamic? And if so, is that a problem for Drupal core to solve, or just a case of "with great power..."?
Manual testing has shown that caching works as expected, also when making use of the new capabilities we are adding. Also, all automated tests pass.

Decide what to do about regions that contain blocks, but eventually render to an empty string. Currently they skip rendering the div.region wrapper, but after the patch the wrapper is rendered. See comment #43.

User interface changes

none

API changes

none (see also comment #34)

Data model changes

none

Release notes snippet

Do we need one?