feat: JSR compatibility

[niusia-ua]

With this PR, we are starting to work on migrating grammY and its ecosystem to the JSR registry.

Specifically, this PR resolves some of the type issues that arise due to JSR's restrictions. Please review all changes carefully and test them on your bots. In general, these changes shouldn't affect the logic of grammY, but it's worth making sure.

For example, the evaluation result has been improved from 47% to 76% (see screenshot). Also, according to JSR, this should have improved the speed of code compilation. The remaining scores are related to the package documentation.

This is just the beginning of the work. In general, the migration to JSR should be fully completed with the release of grammY 2.0. The second version will solve many of the existing problems, as well as move the code from a platform-specific approach to code compilation to capability-driven code behaviour. This will allow us to fully rely on JSR to support multiple platforms.

You can test the build locally. To do this, first run JSR on your machine as instructed. Then publish the grammY package using JSR_URL=http://jsr.test deno publish. The package will be available at http://jsr.test/@grammyjs/grammy, and the NPM build at http://npm.jsr.test/@jsr/grammyjs__grammy. In the metafile of the NPM build, you can find a link to an archive that you can download and unzip to view its contents. Such a build is suitable for publishing to NPM, except that it needs to be edited and repackaged a bit.

[niusia-ua]

Should I add a --allow-env option to the deno task test? I don't know why it is required.

[KnorpelSenf]

Should I add a --allow-env option to the deno task test? I don't know why it is required.

It might be required we type-check certain code using type definitions defined in npm: deps?

[niusia-ua]

It might be required we type-check certain code using type definitions defined in npm: deps?

It seems so. It works on the main branch.