Research PR-issue automation for CLI

[matejchalk]

Use GitHub Actions (use what's in the marketplace) to automate the following:

• [x] when a PR is opened, author should be assigned automatically
• [x] when a PR changes a package (e.g. plugin-eslint), the corresponding label should be assigned
• [ ] when a PR is linked to an issue, issue status should change to "In review"
• [ ] when a PR is linked to an issue, all of the issue's labels should be added to the PR
• [ ] when a PR is not linked to an issue, it should be added to Project board with "In review" status
• [x] when a PR title is created or changed, it should be checked with Commitlint
• [ ] when a PR cannot be merged because of conflicts, a "has conflicts" label should be added (and removed once conflicts are resolved)

[kristihoskova]

We will do the simple ones and the others that needs more refinement will be separated to another issue.

[IKatsuba]

There is a problem with the "has conflicts" label. The default pull_request workflow trigger does not work when PR has conflicts. It can do pull_request_target, but this trigger has some security notes.

The problem is more complex. We may need to prioritize this option in a separate issue.

[IKatsuba]

Some thoughts about linked issues:

• PR can have more than one linked issue
• linked issues can be accessed with GraphQL API. But if I understand right, there will be ALL linked issues.
• linked issues can be accessed with PR body parsing. We can find keywords like closes and assume it is the linked issue.

[BioPhoton]

@vmasek lets close it