Bash CI CI-KILL label added

[TerrenceMcGuinness-NOAA]

Description

This PR adds a kill label CI-Kill that will cancel all pending jobs and builds of a bash CI that has all ready proceeded passed the Ready state.

Previously one could only "reset" a CI Bash run but a typical use case is the user wants to stop/kill a CI test and restart it later. Just add the CI-Kill label to any CI job in progress.

• CI checks to see if any Bash CI is passed Ready (if it still just Ready simply remove it)
• If the CI state is Building or Running it will quit the build and/or cancel all pending scheduled jobs
• Completely deletes the PR directory
• Removes the Kill and all other CI labels
• Reports actions in comments to user in PR

Resolves #2067

Type of change

• New feature (adds functionality)
• Maintenance (adds CI functionality)

Change characteristics

• Is this a breaking change (a change in existing functionality)? NO
• Does this change require a documentation update? NO

How has this been tested?

Ran Bash CI in development space and CI-KILL'ed several runs at different stages

Checklist

• Any dependent changes have been merged and published
• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• My changes generate no new warnings
• New and existing tests pass with my changes
• I have made corresponding changes to the documentation if necessary

[WalterKolczynski-NOAA]

What happens if one PR is marked ready and another is marked kill in the same polling interval? If I'm understanding this code, the kill label would be ignored until the next poll.

Additionally, if you remove the kill label you create a race condition among all CI platforms and only one will see it. Not an issue if we're only using bash on one platform (as Orion right now, or WCOSS in the future), but a problem if there are multiple.

I'm also not sure about interweaving the kill functionality throughout the code that kicks off PRs. It violates the single responsibility principle. Can the kill be in a separate script (or at least separate function)? If there are places where the two share code, those pieces can be abstracted out to functions that both call.