1733 paredit awaitable

[PEZ]

What has Changed?

Changed a lot of paredit code to stop using void on the edit promises and instead return them. At some places we were doing return await, and there I removed the await.

Also changed the Paredit extension command handlers to always return the promise to whoever is using the commands. E.g, a Joyrider:

Fixes #1733

My Calva PR Checklist

I have:

• Read How to Contribute.
• Directed this pull request at the dev branch. (Or have specific reasons to target some other branch.)
• Made sure I have changed the PR base branch, so that it is not published. (Sorry for the nagging.)
• Updated the [Unreleased] entry in CHANGELOG.md, linking the issue(s) that the PR is addressing.
• Figured if anything about the fix warrants tests on Mac/Linux/Windows/Remote/Whatever, and either tested it there if so, or mentioned it in the PR.
• Added to or updated docs in this branch, if appropriate
• Tests
  • Tested the particular change
  • Figured if the change might have some side effects and tested those as well.
  • Smoke tested the extension as such.
  • Tested the VSIX built from the PR (so, after you've submitted the PR). You'll find the artifacts by clicking Show all checks in the CI section of the PR page, and then Details on the ci/circleci: build test.
• Referenced the issue I am fixing/addressing in a commit message for the pull request.
  • If I am fixing the issue, I have used GitHub's fixes/closes syntax
• Created the issue I am fixing/addressing, if it was not present.
• Formatted all JavaScript and TypeScript code that was changed. (use the prettier extension or run npm run prettier-format)
• Confirmed that there are no linter warnings or errors (use the eslint extension, run npm run eslint before creating your PR, or run npm run eslint-watch to eslint as you go).

Ping @PEZ, @bpringe, @corasaurus-hex, @Cyrik

[Cyrik]

I think in general I'd rather see the promise returned. When you do it async but only return the result, you're taking away the option for the caller to run them in parallel with something else.
The question is if it's ever useful to run any of this in parallel. But even if there's not, we're taking away an option without gaining anything.

[PEZ]

Thanks for the general pointer @Cyrik! 🙏 I have updated the PR according to that and we now return the promises all the way out to any user of the commands (via vscode.commands.executeCommand(). So if they want to try use the commands in parallell, they can. (And they will suffer from it, but we are not patronizing 😄.)