CI: Add a workflow to automatically label pull requests

[dfandrich]

The labeler language is quite restrictive right now so labels are added
quite conservatively, meaning that many PRs won't get labels when it's
"obvious" they should. It will still save some manual work on those
that it can label.

If this labeler were already running, it would have labeled this PR with "CI".

[dfandrich]

Actually, the action is running and it did add a CI label!

[jay]

If this is case sensitive then it is 'winbuild' in lowercase. Also I think it should be added to the build tag if the labeler allows multiple tags to be applied to the same path.

[dfandrich]

Done and done.

[dfandrich]

I've added a few more documentation files & build paths.

[jay]

Let's see what happens.

[dfandrich]

The first workflow runs ran with GITHUB_TOKEN Permissions PullRequests: write but now they're running with PullRequests: read and failing with the error Error: HttpError: Resource not accessible by integration. The only difference that seems relevant is that the original PRs were on the curl repo but the PRs were on other people's repos. I wonder if that is the difference.

[dfandrich]

I think that's it. According to the docs, Maximum access for
pull requests from public forked repositories: pull-requests=read so GitHub is downgrading the write access we want on other people's PRs. That makes this workflow almost useless.

[jay]

what about s/pull_request/pull_request_target like this guy

[dfandrich]

I didn't notice that pull_request_target difference; I used the default template that was spit out for this action that had pull_request. I've submitted that change that, hopefully, will improve things. ReviewPad is considerably more powerful and can automate more things for us, but if people are hesitant about adding another app to the curl repo, and the labeler action merges my PR to add allofany patterns, this workflow will handle 90% of the labels I'd like to create ATM.