Introduce SubTask.getOwnerExecutable

[jglick]

#5733 introduced a way to go from PlaceholderExecutable to WorkflowRun using supported APIs. For example: a Pipeline job

node('some-label') {
  sh 'something'
}

is running the sh step, and given the node block executor slot you want to look up the build which encompasses that (and perhaps other node blocks). However, if some-label were currently unavailable and this item was sitting in the queue waiting to be scheduled, there would be no PlaceholderExecutable yet, only a PlaceholderTask, and there was no supported way to find the corresponding WorkflowRun. Various plugins therefore added a dependency on workflow-durable-task-step and directly cast to PlaceholderTask to call its run or runForDisplay methods; for example I could find jenkinsci/blueocean-plugin#2388 as well as jenkinsci/throttle-concurrent-builds-plugin#197 (though for now this still needs a workflow-durable-task-step dep due to another call) as well as a number more in less common plugins. This new API allows the navigation to the owning build to be done in a proper way, assuming jenkinsci/workflow-durable-task-step-plugin#287.

Testing done

N/A

Proposed changelog entries

• Developer: Introduced an API SubTask.getOwnerExecutable to be implemented in Pipeline.

Maintainer checklist

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

• There are at least two (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 is not blocking the change.
• Changelog entries in the pull request 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, the upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the pull request title (see 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).

[NotMyFault]

/label ready-for-merge

---

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