CredentialsProvider: extend public API with find*() and get*() method variants that can specify the Run

[jimklimov]

Until now the build or run reference passed into some methods was used to get its "parent" (such as a Jenkins Folder) and use it as context for persistently configured credentials; the build was then effectively discarded during lookups in available credentials stores (not passed into methods that CredentialsProvider descendant classes can actually override).

With this change, additional method signatures are added which allow the Run argument to be passed further down the road, so credential stores scoped to individual builds (such as with the "Ephemeral Credentials" plugin, hosting pending per jenkins-infra/repository-permissions-updater#5182) can reliably know which code path they were called for during a lookup done by withCredentials, checkout, sshagent and other plugin steps or Java code.

The common entry path for code which wants to find some relevant credentials is to call static CredentialsProvider findCredentialById(id, type, run, criteria) which internally called findCredentialByIdInItem() -- originally the variant which did not accept the run object as its argument, and newly the variant which does.

Default implementations short-circuit to old code without the run argument, so existing plugins should not notice the change until they decide to @Override the new methods.

• Co-authored-by: Claude Sonnet 4.6

Testing done

Experimenting how it goes with work on "Ephemeral Credentials" plugin, currently in a side branch - see https://github.com/jimklimov/ephemeral-credentials/pull/1 - HPI files from a build of that PR and a build of this PR are deployed on an internal testing instance, seems satisfactory (log details posted to that PR).

Changes posted here did not preclude passing of existing credentials-plugin tests, at least locally.
Additional src/test/java/com/cloudbees/plugins/credentials/RunAwareLookupTest.java crafted specifically for passing Run arguments.

For a bit more context: The problem was actually found during work on that "Ephemeral Credentials" plugin: it seemed "obvious" that when we get called from a pipeline or other build, we can know who the caller is, and look up exactly the credentials stored by that build, not by its siblings (same job, different number) or neighbors in a job folder. It turned out that this information is not available in all contexts (e.g. easy to see directly in a pipeline step like withEphemeralCredentials offered by that plugin, but not when some checkout simply iterates all credential stores to see if somebody defines what it asks for). Experiments with discovery of a thread or executor, or looking at call stack traces, proved outright dysfunctional, or unreliable, or too expensive - and in any case they are hacks that would likely be broken sooner or later by evolution of Jenkins and/or Java. So the best solution is to directly hand down the relevant information this plugin already has, just chose to forget until now.

Submitter checklist

• Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
• Ensure that the pull request title represents the desired changelog entry
• Please describe what you did
• Link to relevant issues in GitHub or Jira
• Link to relevant pull requests, esp. upstream and downstream changes
• Ensure you have provided tests that demonstrate the feature works or the issue is fixed

[jimklimov]

Consuming PR changed to jenkinsci/ephemeral-credentials-plugin#2 now that the new plugin is hosted.