Add ctx.send* methods and optional useNewReplies from telegraf/future

[MKRhere]

It has been a long-confusing feature of Telegraf that ctx.reply doesn't actually reply, but sends a message in the same chat. We now plan to fix it. This PR introduces ctx.sendMessage, ctx.sendPhoto, etc., that reflect the upstream API, but implicitly send a message in the same chat, more consistently with the other Context methods. This is the current behaviour of the ctx.reply methods.

This PR also introduces the new reply mode, which is optionally enabled using the useNewReplies middleware. Demonstration:

import { Telegraf } from "telegraf";
import { useNewReplies } from "telegraf/future";

const bot = new Telegraf(token);

// current behaviour:

bot.on("message", ctx => {
  // sends message in the same group, but doesn't reply
  ctx.reply("Hello");

  // sends message in the same group, but doesn't reply
  ctx.sendMessage("Hello");
});

bot.use(useNewReplies());

// new behaviour:

bot.on("message", ctx => {
  // actually replies to the message that was received
  ctx.reply("Hello");

  // sends message in the same group, but doesn't reply
  ctx.sendMessage("Hello");
});

This causes ctx.reply, ctx.replyWithPhoto, and the like to actually reply to the message in current context. If a message is not available, it will simply send a regular message.

A future minor release of telegraf will deprecate the current ctx.reply* methods in favour of the new ones, causing their usage to log warnings, prompting users to enable useNewReplies. v5 will completely replace the behaviour of ctx.reply with the new reply methods, and an optional middleware, useOldReplies, to replace them with the old methods may be added.

[wojpawlik]

The history is a little messy already, I suggest merge-squashing or rebasing before merging.

an optional middleware, useOldReplies, to replace them with the old methods may be added.

Just throw away the old behavior, that's the point of a major release.

[KnorpelSenf]

I will review this in a few days, my time is currently a bit limited. Please don't wait for me if prefer to merge before I get to this.

[wojpawlik]

I see no reason to rush this

[MKRhere]

@wojpawlik

I suggest merge-squashing or rebasing before merging

I have rebased, but prefer not to squash history. Rather than treat git as a changelog, I prefer to treat it as a devlog.

Just throw away the old behavior

Okay, I've updated the PR description to reflect this

@KnorpelSenf

my time is currently a bit limited

No pressure; I might merge after some more testing to make sure nothing is breaking. If you get time meanwhile, appreciate a review.

[MKRhere]

This PR is ready to merge into feat-api-6.2, and I'll bundle them into one release at 4.9.0. However, I'm not merging yet so as to not clog reviews on #1671. When #1671 is approved and ready to be merged, I'll merge this first.

[wojpawlik]

Why not merge this into v4 right now?