Cleanup of Project object contract/constructor

Not a stable blocker for Drupal CMS.

This also need not be on our radar for a general release of Drupal CMS. Re-categorizing as a beta blocker because the Project class is API, which can change in alpha releases but not in beta.

$warnings is used extensively in the Svelte code, but the backend is a different story. The only source plugin which uses it is ProjectBrowserTestMock. The fact that it's not used by the DrupalOrgJsonApi source suggests a few possibilities:

• The functionality is supposed to exist but the DA hasn't implemented it yet.
• The functionality doesn't exist, and won't - the property was merely added to support an API feature that never materialized.
• The functionality exists at the drupal.org end but the DrupalOrgJsonApi source doesn't take advantage of it.

This probably needs input from @fjgarlin.

I think it was just to replicate what was done in here: https://git.drupalcode.org/project/drupalorg/-/blob/e31465608d1380345834...

ie: https://www.drupal.org/project/ckeditor →

From the API endpoint is just a taxonomy term value, and then it’s really up to PB what to do with it. I think it can be cleaned up, and if we want to implement it, it can be done from scratch taking into account what is it we really want.

Currently, PB and filters only care about: active status and maintained status. In the early days, we were checking each possible value, and marking/showing some as "negative", but that changed with the introduction of other Plugins and it makes no sense anymore.

Should we want to show the descriptions of the values for the taxonomies, we could always do it, without the need to show a warning triangle.

That makes sense to me. I think $warnings, as implemented in HEAD, is too generic and semantically meaningless. It really should be something like $flags, and that should be an enum case, or array of enum cases, that have specific meanings and can be rendered in specific ways by the Svelte code.

So +1 for removing it for now.

This looks really good from a code perspective, but at least one bug.

It seems like ones that should have the default/fallback logo are instead using the logo of the previous project that has one set. so in 2.0.x, Scheduler has a logo, but File Entity does not. Feeds does, but the three after Feeds do not, etc.

Once you get out of the top 100 you see a bunch that don't have logos (my favorite is going to page 5) on the drupalorg_jsonapi source.

FIXED THAT. Super dumb bug -- the DrupalOrgJsonAPI source wasn't resetting $logo as it loops over the projects.

Since this is a bug in the actual source plugin, not the Svelte code, I'm no longer sure it benefits from a test.

This is a great clean-up. I'd like to see a test for #17, I'm actually surprised PHPStan didn't catch that. But that can happen in a follow-up.

We made it!