Design a "bot" to assist "managing" of the dandisets by authorized users

DataLad dandisets are not "sources", they are automagically updated by a cron service running on drogon. As such we should not give any write permissions to original authors/owners of the dandisets as known to the DANDI system.

Only DANDI archive has information about which users have write access to the original dandiset, and thus should be capable e.g. to

- modify list of users associated with dandiset in `Triage` role. E.g. `@dandibot add @login1 @login2 to the dandiset`, `@dandibot remove @login1 @login2 from the dandiset` (#360)
- "accept" PR, if any is sent out to e.g. fix an issue in some sidecar/text file - thus opening easy ways to fix up dandisets via github. E.g. `@dandibot accept PR`
- resync labels (#361)
- ...

It will be responsibility of the bot to first verify that the author of the command is among authors of the dandiset to operate on the command.

Such bot service might also help to show/seek confirmation from the authors for some scheduled/mass maintenance tasks etc as we mind stormed with @rly during ODIN, e.g.

- upgrade `.nwb` files:
- from some ancient version (e.g. 1.0a) over to a newer one
- upgrade dandisets with some auxiliary metadata (e.g. semantic annotations etc)

Some extra "cron" jobs which might need to be performed but not necessary need to be a part of "bot" I guess:

- checking list of each dandiset users with Triage role which had been invited but have not confirmed/responded (removed themselves), and email a reminder/instructions on how to accept invitation or remove themselves (#360). Actually -- we might not want to remind if at least one "Triage" user has replied. The others might be PIs etc, not desired to pester if already somebody took care.

TODOs (yet to be finalized)
- [ ] check out e.g. conda-forge bot(s). They must reflect lots of knowledge/best practices to design such beasts
- [ ] ...

refs:
- https://github.com/dandi/dandi-archive/pull/1595