Expose both pipeline_ref and source_ref for pipelines webhook events

Context

We noticed in https://gitlab.com/gitlab-org/quality/engineering-productivity/triage-ops-playground/-/merge_requests/17#note_2098489782 something odd with the pipeline webhook events. It seems that the ref attribute is the ref value from the merge request instead of the pipeline.

It is inconsistent with the Pipelines API, which will return the pipeline_ref in the ref attribute.

It was apparently done on purpose in gitlab-foss!28772 (merged). This comment explains it best:

This is a similar fix with https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/27663. In some places, we use ref for showing a generic branch name, such as use-source-ref-name-in-webhook, and in the other places, we use ref for getting data of ci_pipelines.ref, which could be a generic branch name OR full ref path, such as refs/merge-requests/:iid/head.

For the pipeline webhook payload, users do not care the full ref path as well as they don't care in CI_COMMIT_REF_NAME predefined variable. Thus, we can just change the ref value to be pipeline.source_ref.

As for this part of the comment:

For the pipeline webhook payload, users do not care the full ref path as well as they don't care in CI_COMMIT_REF_NAME predefined variable.

This isn't true as far as Engineering Productivity is concerned, because we use the full ref from the pipeline webhook event to determine whether the pipeline is a merged results pipeline.

Goal

Expose both the pipeline_ref and the source_ref in the pipeline webhook event, so that people can choose to use either.