Check for github action updates monthly

[jlosito]

Requirements for Contributing to this repository

• Fill out the template below. Any pull request that does not include enough information to be reviewed in a timely manner may be closed at the maintainers' discretion.
• The pull request must only fix one issue at the time.
• The pull request must update the test suite to demonstrate the changed functionality.
• After you create the pull request, all status checks must be pass before a maintainer reviews your contribution. For more details, please see CONTRIBUTING.

What does this PR do?

This will use dependabot to check for updates against any github action which this project uses.

https://docs.github.com/en/code-security/dependabot/working-with-dependabot/keeping-your-actions-up-to-date-with-dependabot

I noticed that there were a out of date. For instance, the stale action is currently on major release v6 and this project is still using version 1.

Description of the Change

A pull request with version bumps will be submitted on a monthly basis for any github action which this project uses.

Alternate Designs

Could use renovate for another automated solution or one could manually check for updates on a scheduled basis. Depedanbot is sort-of built into GitHub as an automated solution making it easier to implement in my opinion.

Possible Drawbacks

More pull requests to look at which can be annoying. I tried to reduce that as much as possible by making the interval as monthly instead of something more frequent such as daily.

Verification Process

There are a couple of actions which are currently out of date, so as soon as this is merged, there should be a couple of pull requests generated.

Additional Notes

Release Notes

Review checklist (to be filled by reviewers)

• Feature or bug fix MUST have appropriate tests (unit, integration, etc...)
• PR title must be written as a CHANGELOG entry (see why)
• Files changes must correspond to the primary purpose of the PR as described in the title (small unrelated changes should have their own PR)
• PR must have one changelog/ label attached. If applicable it should have the backward-incompatible label attached.
• PR should not have do-not-merge/ label attached.
• If Applicable, issue must have kind/ and severity/ labels attached at least.