Add nrepl message log

[bpringe]

What has Changed?

• Adds a command for toggling nrepl message logging on and off - "Toggle nREPL Message Logging Enabled"
• When nrepl logging is enabled, and output channel called "nREPL Messages" is created and shown. nREPL messages are logged to this channel, and you can see the direction in which the message travelled.
• The command is enabled at all times, whether or not the repl is connected. This allows logging of messages as soon as a repl is connected (if logging is enabled before connecting a repl).
• When nrepl logging is disabled, the channel is hidden and disposed.

Closes #1198

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
• 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. NB: You need to sign in/up at Circle CI to find the Artifacts tab.
  • Tested the particular change
  • Figured if the change might have some side effects and tested those as well.
  • Smoke tested the extension as such.
• 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
  • If I am fixing just part of the issue, I have just referenced it w/o any of the "fixes” keywords.
• Created the issue I am fixing/addressing, if it was not present.

The Calva Team PR Checklist:

Before merging we (at least one of us) have:

• Made sure the PR is directed at the dev branch (unless reasons).
• Figured if anything about the fix warrants tests on Mac/Linux/Windows/Remote/Whatever, and tested it there if so.
• Read the source changes.
• Given feedback and guidance on source changes, if needed. (Please consider noting extra nice stuff as well.)
• Tested the VSIX built from the PR (well, if this is a PR that changes the source code.)
  • Tested the particular change
  • Figured if the change might have some side effects and tested those as well.
  • Smoke tested the extension as such.
• If need be, had a chat within the team about particular changes.

Ping @PEZ, @bpringe

[PEZ]

Awesome to finally see this happening! Haven't tried it yet, hopefully I get to do that during the day.

[bpringe]

I think the code is ready now, I just need to add info to the docs about it.

@PEZ Where should this go in the docs? We have multiple places for troubleshooting info about specific subjects on those particular pages. I'm not sure if this warrants a new, general troubleshooting page, or if we should fit it into some existing page.

[PEZ]

For now we can slap it in here https://calva.io/connect/#troubleshooting maybe? Hmm, that is not a perfect fit at all. Maybe instead create a page cider-nrepl that goes just before the Clojure LSP page, and put the info about this trace there, and link to it from the connection troubeshooting section. Then add an issue to give the new page more love. WDYT? My rationale is to keep it incremental so that this awesome feature does not get locked up in documentation jail. 😄

[bpringe]

That sounds good to me! I'll be busy this weekend, but will get to it soon.