Improve collaboration between ansibullbot and collection_bot

This is also a possible path forward to solve https://github.com/ansible-community/collection_bot/issues/14.

The collection_bot is based off ansible/ansibullbot, unfortunately since the last rebase which was around August 2020 there have been many changes in ansibullbot most notably various refactorings and code cleanups that would make rebasing at this point difficult. Even if we did that future rebases and cherry-picks would still end up being difficult due to the way how collection_bot is built on top of ansibullbot (effectively not separating collection specific functionality). So to make sharing of changes that could both projects benefit from (using changes from ansibullbot in collection_bot and vice versa) possible I propose the following:

Start with a fresh fork of ansibullbot (💥 #14 can be closed now).
Create a new triager class, probably by subclassing AnsibleTriage from ansibullbot/triagers/ansible.py, that would only implement changes specific to collections that were made in https://github.com/ansible-community/collection_bot/commits/main - not all changes are needed anymore though.
Optionally, collection specific changes in plugins could be made into separate plugins.
Create an entry point similar to ansible_triage.py for the new triager.

The obvious downside is that the collection_bot would have to be "re-implemented".

This would allow for easier sharing changes made in the code common for both projects and avoiding a need to create the same PR for both projects like https://github.com/ansible-community/collection_bot/pull/24 and https://github.com/ansible/ansibullbot/pull/1497 - and possibly diverging both code bases even more by forgetting to submit changes to one of the projects.

Does that sound sensible?

@mkrizek Thank you for the detailed steps

Reviewing https://github.com/ansible-community/collection_bot/pull/5 which contained most of the work needed There are other PRs, though #5 was where most of the work was done

work in progress list of what needs doing

List of functionality that may need adding to ansibullbot

Priority

[ ] Don't hardcode repo name -- define list in config file)?
[ ] Pull issue templates from .github repo - Initially just copy them into .github/ISSUE_TEMPLATE dir
[ ] cachedir should be based on repo name (so you can have multiple instances)

Later on

[X] Don't harcode botname - done in upstream C.DEFAULT_BOT_NAMES.
[ ] Loop over multiple repos define list in config file)
[X] Deprecate GitHub webscraper -- Done in upstream (removed)
[ ] Different GitHub Teams depending on repo ansible_core_team -- possibly move to list in config file? - Shouldn't just be ansible vs ansible-collections. Content Teams collections may want a different list of peopl
[ ] Don't hardcode branch name - Can we look this up
[ ] Various things related to labels, see #5
[ ] Review rebuild_failed logic and here and here
[ ] Don't label PRs as backports (unless they are against the stable branch -- Put list of branches in the config file?
[ ] ansible-core version
[ ] Drop check for multiple new modules (can be removed from upstream
[ ] Some collections have symlinks
[ ] test vs tests directory name
[ ] cachedir should be based on repo name (so you can have multiple instances)
[ ] Deployment playbooks/group_vars/all.yml
[ ] templates/*.j2 to be passed full repo path -- Common
[ ] Don't spam maintainers in same directory #19
[ ] GitHub label creation script: scripts/labels.*
[ ] Don't close forks made by bots #10
[ ] ~~support:community #16~~ (we won't use support labels, unrelevant post ansible-base split) ...

Checked items imply this functionality is available in ansibullbot

List of use-cases to test

Based on the above list we need to check the following to ensure this still work

[ ] Correct labeling when module symlinks exist (c.g & c.n)
...

Code changes

[ ] Create new triage class
...

Notes

Potential three-way diff
- collection_bot
- August
- Upstream

ansible-community / collection_bot