[JENKINS-54323] Add setBuildInfo step

[dwnusbaum]

See JENKINS-54323. Complements #71.

This PR adds a dedicated step named setBuildInfo (I don't feel too strongly about that name, so let me know if you'd prefer something else) for setting Run.description, Run.displayName, Run.keepLog, and Run.result. This step would get rid of one of the use cases that currently requires RunWrapper.

Right now, I've created a single step that takes a specified Describable in its constructor:

setBuildInfo(description('description here'))
setBuildInfo(displayName('display name here'))
setBuildInfo(keepLog(true))
setBuildInfo(result('FAILURE'))

The other approach that would make sense to me would be to have a dedicated step for each field:

setBuildDescription('description here')
setBuildDisplayName('display name here')
setBuildKeepLog(true)
setBuildResult('FAILURE')

I chose the describable approach because I initially allowed a list to be passed to the step, but that didn't seem very likely to be useful in practice, so I simplified it, at which point a dedicated step for each field seems like the better approach. I'm putting this up as-is to see what people think, so let me know if you have a strong preference for either implementation.

@reviewbybees

[abayer]

Looks good at first glance to me - do we want to have a get equivalent as well?

[dwnusbaum]

@abayer Yeah, I wasn't sure if we wanted that to be handled along with the API step (i.e. as shims on top of specific API queries), or if we should just implement the common ones directly in the obvious way. Thoughts?

[abayer]

Oh yeah, forgot about that. Well...hmm. I'd say that if we're exposing set for these things, get as well via the same approach would only make sense.

[jglick]

The api step already handles the get case (for both the current build and others), so I see no reason to bother with that. For compatibility, the currentBuild shim in off-master would manage gets.

[jglick]

It is required context; you need not and should not check for null.

[abayer]

IDEs tend to glare at you if you don't. =)

[jglick]

Or could be made an ExtensionPoint if the need arises.

[jglick]

rawtypes

[jglick]

a dedicated step for each field seems like the better approach

No particular preference. I suppose the dedicated step is less verbose for users.

[dwnusbaum]

No plans to pick this back up in the near future.