[Proof of Concept only - Do not merge] New transformer registration method that narrows like Composer.on

[KnightNiwrem]

[KnorpelSenf]

I understand that the naming use implies that there should be similar methods like on etc, but I would prefer it if we would not have to extend the API surface for every single method we add.

Instead, we should develop a composer for API transformer functions (called Resopmoc? :D), as it is outlined in the docs at https://grammy.dev/advanced/transformers.

We could then extend the transformer type to something along the lines of MiddlewareFn | MiddlewareObj and pass this composer to bot.api.config.use. It could mirror many of the features that the original Composer has, including the implementation of on found in this PR.

[KnorpelSenf]

Regarding naming, what is your opinion on consistently calling things

• Middleware and CoMiddleware
• Composer and CoComposer
• Context and interface CoContext<M extends Methods<R>, R extends RawApi> { method: M, payload: Payload<M, R> } which allows for narrowing

We could then change the function parameters to (prev, cctx, signal), or optionally integrate the signal into the co-context.

[KnorpelSenf]

This concept is very likely going to be added to a next major version of grammY. If you stumble upon this PR, you may be interested in reading a lengthy discussion we had about the topic today in the group chat: https://t.me/grammyjs/23758

It contains:

• naming ideas
• similar concepts in other fields, such as mathematics and type theory
• why composer and co-composer are complementary
• how composer and co-composer are similar
• information about the scope and impact of the desired changes.