Add 'supported' flag to branches to use to direct users and bots

This is how it looks like (with Gin) on the backend. The update function worked in my manual testing. The checkbox also worked, it saved properly both checked and unchecked.

Ugh, wrong screenshot :D Here is the correct one.

Since the update function and UI all worked in my manual testing, this should be needs review :)

Hm PHPUnit fail seems to be on this second line, which is odd since there is a lot of things passed earlier:

    $this->drupalGet('api/' . $this->branchInfo['project'] . '/duplicates.php/function/duplicate_function');
    $this->assertLinkUrl('foo_function', 'http://example.com/function/foo_function', 'foo_function is linked', 'foo_function link goes to right place');

That said, it also triggers this deprecation:

    1) /builds/issue/api-3524717/web/core/lib/Drupal/Core/Test/HttpClientMiddleware/TestHttpClientMiddleware.php:52
    Renderer::renderPlain() is deprecated in drupal:10.3.0 and is removed from drupal:12.0.0. Instead, you should use ::renderInIsolation(). See https://www.drupal.org/node/3407994

Left feedback in the MR. We should display the "Supported" status in the front-end via the templates that we set in this module.

Happy to show the "Supported" or "Unsupported", whatever makes more sense.

We can also add a test for this. I know some of them are failing in HEAD but most are passing so we can create a new one that proves that it works as expected.

Started adding implementation for the sake of discussion. Looks like the implementation would be slightly different based on which page template it is on. Let's agree on a general direction on some questions:

• Should we have a reassuring message when reading current doc? That may be useful, maybe superflous?
• Should we have the logic for displaying messages in twig or in the formatter?
• Is this kind of approach to do a per page type level direction is good or is there a good way to abstract this? (There will be lots of copies of this message otherwise, maybe it should be part of the navigation method/logic, which is added on all pages?).
• Is this markup what we want to use to wrap this message? Would this show fine on api.drupal.org (it looks quite bad on Olivero, but it should pop on api.drupal.org :D).

For comparison this is the visual treatment that Symfony uses inform users:

> Should we have a reassuring message when reading current doc? That may be useful, maybe superfluous?
Happy either way. For simplicity, I would add it, but I'm happy as well if nothing is shown (no-news-is-good-news type of thing)

> Should we have the logic for displaying messages in twig or in the formatted?
If we do it in twig, let's make a re-usable template that receives the branch. It could also be done via preprocess functions or in the places where we prepare the variables for the templates. As the logic is not complex, I don't see a problem with it being in twig.

> Is this kind of approach to do a per page type level direction is good or is there a good way to abstract this? (There will be lots of copies of this message otherwise, maybe it should be part of the navigation method/logic, which is added on all pages?).
Good point indeed. Maybe we can make it a block plugin. See the existing ones, as we have a method that would help $this->utilities->getProjectAndBranchFromRoute(). This would avoid duplication in templates.

> Is this markup what we want to use to wrap this message? Would this show fine on api.drupal.org (it looks quite bad on Olivero, but it should pop on api.drupal.org :D).
We can have a follow-up styling issue for bluecheese. But we can also use the "info", "warning", "error" messages styling. Don't worry too much about how it looks in Olivero as long as it's right.

Video of current MR state :) Still does not work on standalone pages, because there is no classic version nav there.

Added messages to alternate handling too. Still need to be cleaned up and figure out how to do canonical propagation to render array from here.