doc: add guidance on console output in tests

I'd like the test writing guide to include some information on expected usage of console.log/error, to avoid having to discuss it (as much) in individual PRs.

As long as I've been writing node.js unit tests (since 0.10), I've written my tests with console.log statements (or added them while debugging), then removed them before PRing the changes. I'm not entirely sure why this is the node.js convention, or even if it is widely agreed that its the convention (I count over 200 tests with 2 or more calls to console.log() or console.error()).

Output is surpressed by the test runner if the test passes, so it does not increase the noise/verbosity of most test runs, but it will be included as context if a test fails.

Since its going to be in the tap output and show up in jenkins, as well as the local display, the output should not be so excessive as to overwhelm the display, but other than that, I can't see why anyone other than a test author/maintainer should have concerns over what the test outputs.

What do other @nodejs/collaborators think?

If the consensus is that console output should be avoided, I'll modify the text. No matter what the text ends up being, by documenting it, it should make PR review clearer since there will be agreement on the general policy.

cf. discussion with @jasnell and @addaleax preceeding https://github.com/nodejs/node/pull/26209#discussion_r262605089

Checklist

• documentation is changed or added
• commit message follows commit guidelines