Rework module to work without a separate computed field

For my cases it works well, so let's move to "Needs review" to check how it works for others.

Will this recursively load info for blocks that have entity reference fields (Media, taxonomy, etc)?

Here is a quick add on for this patch that does the following:

1. Checks if $item['layout_builder__layout'] is empty.
2. If so, load the entity type and its bundles entity view display information.
3. If the entity view display is layout builder enabled, load the third party settings and get that information.
4. Populate $item['layout_builder__layout'] with that information and proceed as normal - adding the entity view display entity as a cacheable dependency.

This was important in getting layout builder information for decoupled sites for nodes that are NOT overridden, or may not be able to be overridden in layout builder. Otherwise, the array is empty - but you DO have layout builder information at the display level. It should pass it.

Attaching a second patch. This one will sort the blocks in their proper order so it is easier to work with on the client side.

  /**
   * Sort blocks within sections by their weights so the order is correct in JSON:API.
   *
   * @param array $section_data
   *   A set of layouts and components within a section.
   *
   * @return array
   *   The sorted components.
   */
  protected function sortSectionComponents(array &$section_data): array {
    foreach ($section_data as &$section_components) {
      usort($section_components['components'], fn($a, $b) => $a['weight'] <=> $b['weight']);
    }

    return $section_data;
  }

I noticed that core does not store the order of items correctly, region or weight. This updated patch attempts to set that order while building the response so the frontend does not have to bear that burden.

Updating patch. Reworked some of the logic and addressed issues when viewing entities that are not Layout Builder enabled.

We used the patch from #9 in our project and it worked fine except for supporting the includes tree.

Our case:

Node with layout builder, inside layout builder layout added some blocks with paragraphs (just a basic block type with a paragraph field) -> paragraphs were not included even after configuring default includes.

What helped:

Adding "include" parameter before

    $this->rootParser->parse($response);

Attaching patch file

That could have been overlooked, sure - I don't use Layout Paragraphs or Paragraphs.