[Draft] Present HEAD commit from source branch instead of merged commit in PreBuildMerge plugin

[jangalda-nsc]

JENKINS-52926 - Present HEAD commit from source branch instead of merged commit in PreBuildMerge plugin

Linked issue is not completely resolved by this PR. This PR relates to my comment in linked ticket and should resolve a problem of displaying sha of merge commits, which makes hard to determine cloned code revision without looking into logs.

This is a draft PR, I'll add documentation, docstrings and clean code a bit if solution is approved. I'll be grateful for any feedback - what else should be added, alternative implementations, etc.

This PR introduces new option to PreBuildMerge extension, which allows to choose revision included on Git Build Data summary page. By default, the merged revision is displayed to keep backward compatibility. The other option is to display head of a source branch. In some cases this is more useful information, for example when we want to know which revision from PR branch was build, instead of getting the randomly generated commit, which does not exist on remote.

I didn't want to break any existing behavior, so I decided to not change revision returned by decorateRevisionToBuild method.

Unfortunately, this PR do not fix original problem from linked PR - there are still a few build entries. I can open a new ticket if it is required to merge this PR.

Checklist

• I have read the CONTRIBUTING doc
• I have referenced the Jira issue related to my changes in one or more commit messages
• I have added tests that verify my changes
• Unit tests pass locally with my changes
• I have added documentation as necessary
• No Javadoc warnings were introduced with my changes
• No spotbugs warnings were introduced with my changes
• Documentation in README has been updated as necessary
• Online help has been added and reviewed for any new or modified fields
• I have interactively tested my changes
• Any dependent changes have been merged and published in upstream modules (like git-client-plugin)

Types of changes

• Bug fix (non-breaking change which fixes an issue) ?
• New feature (non-breaking change which adds functionality)

Further comments

Other possible solutions:

• adding a method to hudson.plugins.git.Revision class from git-client, which returns a string with display version of revision. This method by default returns getSha1String(). Then, creating a new class in git-plugin, which extends Revision class and overrides new method.
  Pros:
  - Probably the cleanest solution from git-plugin point of view.
  - Changes are required only in PreBuildMerge implementation and jelly files.
  - Backward compatible
  Cons:
  - New method in Revision, which is useless from git-client point of view
  - Chanes required in 2 repos

• returning marked revision from decorateRevisionToBuild method if user set displayRevision = source_branch.
  Pros:
  - Only a few lines of code needed
  - Backward compatible because default behavior remains the same
  - Probably fixes problem with duplicated Git Build Data
  Cons:
  - In case of displayRevision = source_branchnot only display value is changed, so there might be some unexpected behaviour