Restrict the plugin's ability to control which filters are available

APPROACH 1
One idea is to have a "Utility" class that checks for certain labels, and then we can call that class from the Controllers, once the data has been retrieved. If the check goes well, then we continue as it is. But if it's not, what shall we do?
* A user message won't be helpful as the user won't be able to do anything to fix it
* Not rendering any data seems a bit drastic but I guess it is what we want here. If in the future we have multiple plugins bringing information, I guess we'll just ignore the data coming from plugins that fail this check.

So, while this issue makes sense, I think it's too early to implement and might not be even needed at all (see the below).

--

APPROACH 2
We might want to have a "primary" plugin and then "secondary" plugins, and then force these to follow what the primary dictates (most likely drupal.org). Somehow "hardcoding" additional checks in this module that could even make the d.org plugin fail if it ever changes a label feels inappropriate as we should trust fully the (future) default plugin and its data.

I think that it would make sense to have the default plugin dictate the values that will be needed from other plugins (as opposed to having this module doing it).

So:
* If only one plugin is enabled, everything works as it works now, no additional checks.
** ie: gov sites might only want to allow gov-approved modules and they can create their own plugin. This module could handle that perfectly.

* If more than one plugin is enabled (future issue).
** Define a "primary" plugin to read the filters from. That'll be the "source of truth".
** All filters are still read from the main plugin, so no change in the front-end and we don't even query the secondary plugins for filter data.
** Each "secondary" plugin should implement a "map" when querying the data to convert vocabularies.
** Add the possibility for plugins to be declared "primary only". I'm thiking that d.org plugin will never want to adapt to any other plugin.

Happy to listen your thoughts on the above.

What we really want is a standardized list of statuses, and for each plugin to provide their own mapping.

While these statuses have been stable on Drupal.org, we need the flexibility to change them at any time, without core coordination.

Many issues have been opened over the years about how they are not the best filters, such as #2235021: Add additional granularity to "development status" on projects, #1129394: Allow multiple values in project "Maintenance status" field, #2235021: Add additional granularity to "development status" on projects, #1134450: Automatically degrade maintenance and development status of projects over time. They are indeed non-ideal and not always useful to site builders. We don’t have any specific changes on the horizon, but they are likely to happen in the long run. Currently we can execute this sort of change quickly, once we’ve settled on what to do. We always should be able to do this, and provide immediate benefit to people searching for projects.

Do we need to understand the filters from the front-end perspective only, and then let the plugin decide how we deal with them?

For example, maybe the frontend filters are something like:
- Security: covered by a security policy / not covered by a security policy
- Maintenance: Well-Maintained / not maintained
- Development: Active / Stale

Then we just allow people to include stale, not maintained, or not covered. So on the frontend the user just sees these as more like bools, and then the plugin can decide what status means what. The d.o backend plugin could fetch the list and tids, but I honestly don't know how to do that without having to change SOME code. If we kept the terms the same, that would work - because the tids would stay the same... but if we added something new, I don't see a way around having to update the PB backend...

We don't need to check 'has been replaced' or 'project type=full'?
We are checking the release versions in another place as well?(make sure not getting D6)

Since #5 would mean changes to front-end, controllers and plugins, I'll take this one as it's a similar exercise to when I "decoupled" things in https://www.drupal.org/project/project_browser/issues/3280176

Possible suggestions for filters. From slack conversation here: https://drupal.slack.com/archives/C01UHB4QG12/p1654092626909329

Radio buttons with the following:

- Security: ( o ) Covered by a security policy / (  ) Show all
- Maintenance: ( o ) Well-Maintained / (  ) Show all
- Development: ( o ) Active / (  ) Show all

“Well-Maintained” is not a good label, since it is very subjective. Many of the indicators we have, the maintenance and development status, have options that are good negative indicators. “Actively maintained” and “Under active development” are at best neutral, and shouldn’t be highlighted as positive indicators.

Based on the slack conversation mentioned in #10 and comment in #11, we'll remove the word "Well-".

https://www.drupal.org/project/project_browser/issues/3284347#comment-14...

I still haven't started on this as there are a few issues working on the same components that this will modify. Also, comments like the one linked above still makes me thing that the "main" plugin could dictate what the values should be for now.

In any case, I'm keeping a close eye on the issue queue to see when it can be a good moment to tackle this.

I think this covers the backend side of things. I'll get going with the frontend tomorrow.

This is a big one and it’s ready to review. Assigning to @tim.plunkett for now as we already discussed a while back about this issue.
I’m ok doing a zoom call if needed as it touches files all over the place.

ProjectBrowserSourceBase has “the contract”. It’s an abstract class with some abstract methods and some final methods. That’s the starting point for all the other changes