Refactor comment handling logic

[utdemir]

This PR is an experiment to explore an alternative way to insert comments.

Currently there are two issues we need to solve with our commenting method.

1. Printing comments sometimes affect formatting (eg. it can insert a newline
   between two constructs that's supposed to be on the same line)
2. We "attach" comments to AST nodes, and sometimes we attach the same comment
   to a different AST node after formatting. Both the way we format code
   and the way we attach comments affect this, so just formatting the
   code in a different way can cause issues with the comment placement.

I think, the underlying issue is that currently comment placement
happens automatically when we are printing a located element; and this
can make the formatted code syntactically incorrect, or introduce
idempotence issues.

I can think of a few solutions:

1. Tweak the comment attaching rules and the AST printer code until
   they play well with each other. However I think this might be an
   uphill battle where changing either formatter or the commenting code
   can cause new and more exciting issues.
2. We can attach comments to AST nodes on the parser (probably using
   those "trees that grow" extension points on the AST), and let the
   printer print comments alongside with the source code. This approach
   is probably the most flexible one; since it can both reproduce the
   current behavior, and gives the printers ability to print comments
   in a way they want. However, it is a tedious process to write custom
   comment handling code to every AST element that can be commented,
   and we must still make sure that the comments will be attached to
   the same AST nodes on the second pass.
3. Or we can go the other way around, and stop attaching comments to
   AST nodes, at least directly. The premise is that; in the end, users
   do not comment an AST node; they comment a specific line in the source
   code. So, we can place that comment in the corresponding line on the
   formatted code without looking at AST at all. I think this approach
   will be conceptually the simplest solution. The disadvantage is that,
   not having any information about the AST might make things harder;
   however I believe we can find workarounds for those cases.

In this branch, I am trying the third approach.

1. I format the code disregarding comments. While formatting the code,
   I create a "SourceMap" mapping the SrcSpans in the input to SrcSpans
   in the output.
2. I classify every comment as "Below <line>", "Above <line>" or "Next
   to <line>" according to their location on the input.
3. I map the line numbers of the comments on the input to line numbers on
   the output using the "SourceMap".
4. I attach the comments to formatted output (as a raw Text, without any
   syntactic information),

Currently I only implemented step 1, and am in the process of implementing
step 2 and 3.

This is a relatively big change, so if there is a simpler solution I am
happy to stop working on this branch; and maybe we can revisit the idea
if we keep having similar issues.

[utdemir]

Also, we can remove a lot of stuff if we go ahead with this branch; we can remove those modNewline's from the Internal module, also there are a few lines of code in the Printer.Meat.Value module solely for making comments not break things.

[mrkkrp]

I disagree with

users do not comment an AST node; they comment a specific line in the source code

I think comments are "attached" to things they explain (AST elements) and so if we "move" those things the comments should also move. Your approach seems to confirm that too.

Let's hold on a bit on this one, because

• I'm a bit skeptical of the approach (but I'm happy to be wrong!).
• As far I know there is only one case (with operators) when idempotence is broken. So if we fix this and implement Assert clean run on various packages on CI #303 it should guard against future problems. So, I'd like to try to figure out how to do this when I have time because I've never got to trying this one seriously myself, and so I still optimistic about solving it by less radical means.