feat: allow running JavaScript workers with async methods

[Angelmmiguel]

Add support for async methods in JavaScript workers. For that, I split the JavaScript runtime in two steps:

• Call the requestToHandler method to get the response method / object.
• Convert response to a Promise so we cover all use cases (async / sync).
• Save the final response in a new result variable.

To add support on the JS Runtime side, I upgraded the JS kit to use the new javy crate. It adds new features and a better high-level APIs for running JS code in Rust.

I also included a new example and a new e2e test.

It closes #142

[ereslibre]

LGTM 🎉; this is great!, although I think it would be good to split the main commit into two:

• quickjs -> javy, binary removal
• async feature

[Angelmmiguel]

LGTM 🎉; this is great!, although I think it would be good to split the main commit into two:

• quickjs -> javy, binary removal
• async feature

Sure, let me do it for traceability on the PR, although they will be squashed on main.

[Angelmmiguel]

Done @ereslibre ! 😄

[ereslibre]

👏 Could we merge without squash? I think we can rebase and merge, no?

If so, that would be great! Thanks a lot @Angelmmiguel.

[Angelmmiguel]

👏 Could we merge without squash? I think we can rebase and merge, no?

If so, that would be great! Thanks a lot @Angelmmiguel.

Yeah, that's possible too. However, I usually converge commits into a single one that refers to the PR. Sometimes PRs may include multiple commits like fix: fmt and fix: typo. Instead of asking people to rewrite the git history, I believe it's simpler to limit the PR scope and squash it.

[ereslibre]

Instead of asking people to rewrite the git history, I believe it's simpler to limit the PR scope and squash it.

👍, however if I'm not mistaken the GitHub option "Rebase and merge" does not enforce anybody to rebase their own history, given they will just fast forward on top of these changes.

Anyhow, it's fine by me.

[Angelmmiguel]

Instead of asking people to rewrite the git history, I believe it's simpler to limit the PR scope and squash it.

👍, however if I'm not mistaken the GitHub option "Rebase and merge" does not enforce anybody to rebase their own history, given they will just fast forward on top of these changes.

Anyhow, it's fine by me.

Yeah, that option is available. I usually squash all PRs, but I agree it's interesting to keep the commits separated in main for this specific one. I will rebase and merge the two commits in this one 😄