[JENKINS-62889] ParameterDefinition check for validity

[jeffret-b]

Add an API to ParameterDefinition by which a caller can validate a ParameterValue for that specific definition. This provides a mechanism to ensure that users cannot inject unrecognized values. This is particularly useful for things like ChoiceParameterDefinition, which process a value as a string, but should only allow a specific set of choices.

This new API is optional in two different ways:

1. A subclass of ParameterDefinition has to optionally add implementation to participate in the API. The base implementation just accepts everything as valid because it doesn't know any better. I have added implementations for all of the subclasses in core, though most of them are pretty meaningless. Most of them just check that the value is of the correct class.
2. A caller has to optionally invoke the new API to determine if a value is valid. The only place I know of that currently does anything like this is pipeline-build-step-plugin. I'm preparing another PR for that project to demonstrate usage of this new API.

JobParameterDefinition and JobParameterValue were never completed. These are only used in tests in MockClassUtils in graphql-server-plugin. These should be removed as part of clean up.

See JENKINS-62889.

Proposed changelog entries

N/A

Proposed upgrade guidelines

N/A

Submitter checklist

• (If applicable) Jira issue is well described
• [N/A] Changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developer, depending on the change). 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
• [N/A] 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 correct
• Proper changelog labels are set so that the changelog can be generated automatically
• [N/A] 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)
• [N/A] 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).

[jvz]

Reviewed prior.

[MRamonLeon]

Do you plan to file a PR or ticket to fix graphql-server-plugin after removing these classes? It would be appreciated.

https://github.com/jenkinsci/graphql-server-plugin/blob/ca276ee90ab5d0a5bdad07d4e013eff757112e2b/src/test/java/io/jenkins/plugins/graphql/MockClassUtils.java#L106

[jeffret-b]

We've got sufficient approvals and passing builds so I'm going to mark this as ready-for-merge and let the waiting period begin.