Revert JENKINS-20679 (support for plugin Java requirement metadata)

[basil]

Reverts #3016. See the mailing list thread along with jenkinsci/maven-hpi-plugin#341 and jenkins-infra/update-center2#591. This is dead code, so we intend to stop producing it from maven-hpi-plugin (issuing a warning if users are still trying to specify this in their build configuration) and to stop consuming it from jenkins and update-center2.

Testing done

I did a corpus scan across all OSS and CloudBees plugins for plugins with Minimum-Java-Version in their META-INF/MANIFEST.MF. Almost all results were Java 8 or older. icq-notification and synopsys-sigma were specifying a minimum version of Java 11, but we will be requiring that shortly so I do not see that as being an issue. outbound-webhook was requiring Java 14 but this clearly seemed to be a bug as I was unable to find any reference to the string 14 in that repository's Git history.

I additional did a corpus scan across all OSS and CloudBees plugins for usages of the field hudson.model.UpdateSite.Plugin#minimumJavaVersion and the methods hudson.model.UpdateSite.Plugin#getNeededDependenciesMinimumJavaVersion, hudson.model.UpdateSite.Plugin#isForNewerJava, hudson.model.UpdateSite.Plugin#isNeededDependenciesForNewerJava, hudson.PluginWrapper#getMinimumJavaVersion, and jenkins.plugins.DetachedPluginsUtil.DetachedPlugin#getMinimumJavaVersion with no results.

To test that dropping minimumJavaVersion from the Update Center won't affect older versions of Jenkins, I simulated this condition by setting this.minimumJavaVersion to null in jenkinsci/jenkins/core/src/main/java/hudson/model/UpdateSite.java. I refreshed the update center metadata successfully and updated several plugins without any issues.

Proposed changelog entries

• Remove the ability for plugins to specify a minimum Java version. The minimum Java version of a plugin is always the same as the minimum Java version of the plugin's minimum core version.

Proposed upgrade guidelines

N/A

Submitter checklist

• (If applicable) Jira issue is well described
• Changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developer, depending on the change) and are in the imperative mood. Examples
  • Fill-in the Proposed changelog entries section only if there are breaking changes or other changes which may require extra steps from users during the upgrade
• Appropriate autotests or explanation to why this change has no tests
• New public classes, fields, and methods are annotated with @Restricted or have @since TODO Javadoc, as appropriate.
• For dependency updates: links to external changelogs and, if possible, full diffs

Desired reviewers

@mention

Maintainer checklist

Before the changes are marked as ready-for-merge:

• There are at least 2 approvals for the pull request and no outstanding requests for change
• Conversations in the pull request are over OR it is explicit that a reviewer does not block the change
• Changelog entries in the PR title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood
• Proper changelog labels are set so that the changelog can be generated automatically
• If the change needs additional upgrade steps from users, upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the PR title. (example)
• If it would make sense to backport the change to LTS, a Jira issue must exist, be a Bug or Improvement, and be labeled as lts-candidate to be considered (see query).

[basil]

This PR is now ready for merge. We will merge it after approximately 24 hours if there is no negative feedback. Please see the merge process documentation for more information about the merge process. Thanks!