Clean up end-of-file/printing newline logic

[chenglou]

Our previous final newline logic was messy. These commits clean them up.

When a printer's final newline logic is messed up, this often causes userland to solve it in the printer callsite, editor plugin, editor itself, etc., as has been the case for the old refmt. It wasn't clear who was adding a newline where. Sometime there are no newline, sometime there's one, sometime two. At which point every step of the way folks do a giant string trim on the output and append a single newline at the end and pass the result forward.

Our printer was on the verge of having this problem. For example, we were semi-normalizing the last newline in res_doc, where we appended a newline if the last char isn't already a newline. This is technically a bug, since print (concat [text, hardLine]) and print (concat [text]) both resulted in a single newline.

res_doc wasn't the right place to be opinionated and magical for newline. The right place would be in res_printer.

So these diffs remove res_doc's final newline printing, and add them to res_printer, and only to printImplementation & printInterface.

This has several impacts:

• The outcome printer, which uses res_doc, now doesn't print out a final newline. This is important, as the outcome printer's result is sometime displayed inline as part of a bigger error message in the compiler. We don't want oprinter's result to affect that display. This is consistent with OCaml's oprinter behavior.
• Our own syntax diagnostics output now consistently output 2 newlines between diagnostic, as opposed to sometime 1 newline, sometime 2 newlines (the compiler diagnostics also outputs 2 newlines between error). See res_diagnostics and the snapshots.
• This exacerbate the only printing logic which explicitly added a final newline during its printing: a file with only comments, which is printed using Res_printer.printLeadingComment. This should be fixed. cc @IwanKaramazow for helphis should be fixed. cc @IwanKaramazow for help.