fix(extend-awards): add check for existing branch with pending awards

[brymut]

Description

Currently as described in #1991, when a PR is merged while a PR previously opened by the extend-awards workflow is still opened & unmerged into master, the workflow runs again and overwrites the prior changes.

This PR addresses this issue by adding steps in the workflow to first check if the branch that the workflow creates is available, signalling that there is still a PR open trying to extend the awards.csv file. If there is a branch, the workflow instead pushes a commit to that branch rather than creating a new PR and overwriting changes.

I checked on alternative approaches. Based on the docs for the create-pull-request there is no obvious application/example that addresses this issue. Also, creating differently named branches for each github workflow run would create conflicts as the master branch would change and the master that earlier PR's would be made with would be outdated with new extensions. So I think this is the simplest, most straight forward approach.

Closes #1991

Screenshots

My testing approach was to run this workflow on my fork of this repo and created a test repowith the labels used for extend-awards replicated there. Here is a screen recording demonstrating fixed functionality using the Github web UI:

extend-awards-workflow.mp4

Additional Context

Branch deletion: Since this approach relies on checking if the extend-awards/patch exists to detect if there is an open PR since this workflow creates that branch, we need to delete that branch when we have merged back into master so I have added the "delete-branch" option to the create-pull-request step to do so. As explained in the docs for the Github action, this doesn't delete the branch immediately, so I would recommend that the person merging deletes the branch when they are done. I have added a reminder to the PR message with the same. Alternatively, as mentioned in the docs, the repo could use GitHub's Automatically delete head branches feature in the repository settings.

Checklist

Are your changes backwards compatible? Please answer below:
Yes, AFAIK

On a scale of 1-10 how well and how have you QA'd this change and any features it might affect? Please answer below:
10

[brymut]

Hi @huumn / @ekzyis , I believe this is ready for review.

[huumn]

I'll merge to test it and we'll revert if need be.