Validate core dependencies

[daniel-beck]

Plugins can declare any version number as a core dependency in their metadata.

If a plugin were to specify an incremental or similar non-release, e.g., due to an accidentally merged and released PR depending on future core features, this will result in unpredictable behavior (usually errors of some kind).

Therefore filter out plugins that specify core dependencies that look like irregular releases (RC, incrementals, snapshots, …)

Currently published plugin releases this applies to (and that would be removed):

https://updates.jenkins.io/download/plugins/build-symlink/ 1.0 (2.185-rc28469.6af78cb11bf8)
https://updates.jenkins.io/download/plugins/jcaptcha-plugin/ 1.0 (1.416-SNAPSHOT)
https://updates.jenkins.io/download/plugins/sshd/ 3.0.1 (2.282-rc30905.2ddf35821c11)

Impact should be non-existent, since they're all obsolete releases anyway.

Additionally, use this opportunity to improve robustness: If there is no release of a plugin that is valid, don't throw an NPE somewhere, just skip it. Also don't have an empty entry if there are no releases in plugin-versions.json.

A future iteration of this feature could obtain the list of actually existing core releases so that 2.1000 would not be considered valid (as of early 2023 at least 😁), but this should be a reasonable start.

[jglick]

Note that the build-symlink and sshd cases related to new plugin splits, and that the idiom used at that time would no longer work anyway due to jenkins-infra/jenkins-maven-cd-action#3. Instead we preëmptively block an expected split version using a weekly dep that is one week too old, like in #594.

[jglick]

Seems sane to exclude bogus plugin releases like these, even if one should appear despite other precautions.