#3 Translation layer

The current implementation expects a message in the HTTP request body. That might not always be possible to set up in the webhook configuration; for example, Gitea sends a fixed JSON payload, which cannot be customised. To keep the core http2irc code minimal and clean, this translation layer should not be in there. I can think of two possible implementations: **Modules for core server** External Python modules perform the translation in the request handler. The config file would specify such a module. All used modules would be loaded on config reload. If a module is used for an endpoint, it's called with the raw request object after authentication checks and can then do whatever is needed with it, returning a message string or raising an exception. **Separate web server** A separate web server accepts requests, performs the translation, and sends the resulting message to the main http2irc web server. This translation server could be written such that it does not require any configuration; instead, all relevant information (authentication data and target endpoint on the main server) would go into the request. For example, a Gitea webhook would POST into `https://user:pass@tr.example.org/gitea/target`; the translation server would do its thing and finally forward the result to `https://user:pass@example.org/target`. However, processing should only happen after authentication, and this would require the tr server to start the request, wait for an HTTP 100 from the server, do the processing, and only then send the body. I have not looked into how complicated it would be to implement this with aiohttp, and it might be easy to attack as well. I was first leaning towards a separate server, but after writing this issue out, I think the module idea is easier and cleaner to implement. The `100 Continue` in particular would add a fair amount of complexity for a separate server.