Allow admins to control the names of all commands

[nmlorg]

This is somewhat related to (or at least might be easier due to) #66, but I've been considering this for a while. The idea is to allow bot (and possibly even group?) administrators to control the names of all /-commands the bot responds to, not just ones created using echo or countdown.

One possibility would just be for the MultiBot dispatcher to consult a mapping table, so if it got a Context from ntelebot where ctx.command == 'command1' and it had 'command1' in its table as a mapping for 'events', it would go through the current MODULE.moddispatch (etc.) process just having ctx.command = 'events'.

Another possibility (tying more into #66) would be to go back to a much-earlier idea of having modules register their entry points explicitly (during MODULE.modinit), allowing a more comprehensive UX for managing the command table. A new commands module could actually construct an adminui.Menu based on the target bot's (and possibly target group's) config (which could be used to replace the help module's logic), and its commands.admin could be more explicit in helping admins figure out what mappings are available (rather than expecting them to know all possible commands/figure out the entry points based on just the list of module names).

However this is done (if it's done), care needs to given to things like admin, which has multiple entry points: /admin and /_bootstrap; and possibly for things like events, which conceptually has a single /events entrypoint that branches to /events set, but actually implements it as multiple entry points (and so could be presented to the user either way—a single entry point that branches or both :events and :events_settings (for example) where the default binding is just '/events' → :events, '/events set' → :events_settings).