add batch_invite cmd

[alexeyqu]

This works in a simple way -- as we already store the groups IDs in DB, we can pull them upon the call of /batch_invite and generate links for each chat in a way similar to /invite.

This works as follows:

Questions:

1. Do we want to merge the messages for the chats?
2. Do we want to surface more information about a chat (e.g. description/..)?

[kilomeow]

Alright. Sorry for taking so long to process this PR. The problem here is that unfortunately this change adds a new attack vector and makes the Gretel less secure.

Gretel is designed as a way to respond to a specific incident - the Alice's (Gretel's user) mobile phone is physically taken from her by, let's say P. Then P try to search Alice's telegram. In the current version, P can't access the specific chat until one of participants of this chat manually brings Alice back. However, this pull request breaks that principle. P can manually add Alice to the newly created chat and run the /batch_invite command, then have a list of groups on Alice's phone. Although a little tricky, it is reliable attack, so these changes cannot be accepted as they are.

How can this be avoided? In general, this is not easy, because we give this ability to less trusted participants in less trusted chats. However we still can try /batch_invite whitelisting and blacklisting. Some chats can disallow this option at all (i.e. not to be included in batch invite output), while others will be stored in batch_invite_groups list attached to user. If Alice called /sos or someone used /hide on her, we can assign her a "batch_block" mode (i.e. batch_block: true in database) so batch_invite_groups couldn't be modified. batch_block could be set back to false after someone from batch_invite_groups explicitly invites her back (using /invite or /batch_invite). This is just one of the possible solutions, there are more. Also it could be nice feature to have a /rejoin command as well -- which, unlike batch_invite, initiated by Alice herself.

Although the pull request cannot be accepted like this, I still want to appreciate the contribution. With minimal changes, it is possible to make an alternative version of Gretel that will support batch_invite -- this version could be used as an internal for some organisations. For such usecases it's possible to prohibit adding Gretel to new chats at all, or that only a specific set of telegram users specified in config have this ability. It is easier to implement right now, and requires no changes to the database schema. It seems like there are only two ways - modify batch_invite feature and update the data model for the major version of Gretel or make a custom version of Gretel with this feature.