Reason: Idea: be more lenient about line breaks

[chenglou]

One of the complaints is that refmt's heuristics doesn't format line breaks too well. First, let's make sure it actually does do line breaks a bit better than today. Second, in the worst case, where line breaking is a bit ambiguous, we can always attach an attribute after e.g a structure called [@@linebreak] or whatever. So

let foo = 1;

let bar = 2;

Parses and attaches [@@linebreak] to let foo, and then the printing is idempotent. But if the user writes

let foo = 1;
let bar = 2;

Then no attribute attached, and the printing still idempotently prints to that.

Again, we should just format line breaks correctly in most cases. But it's good to have a fallback idea, or have both at the same time: prescriptive formatting for e.g. let statements, non-prescriptive for, dunno, class properties or something.

cc @jordwalke @IwanKaramazow @let-def @glennsl

[IwanKaramazow]

People use whitespace as a tool to structure code. People familiar with Go or Prettier (who isn't these days?), will find the lack of flexibility in whitespace interleaving pretty counter-intuitive.

I did some experiments with the current formatter based on the Location.t of the ast-nodes.
Every node in the parsetree has it's location attached, so why don't we use that as a heuristic for whitespace interleaving? The Location.t contains the line-height, which we can use to compute if we need to attach whitespace. Example:

- line_height_beginning_structure_two 
- 1
= whitespace_interleaved_between_structure_one_and_strucure_two

The advantage would be that we don't need to attach new properties and modify the parser.
That is if the location attachment is correct 😅

I think I can make the above work, if this sounds like a good approach.
Not yet 100% sure how this is going to affect comment interleaving.

[chenglou]

I don't know the specifics but sounds good. cc @let-def regarding affecting comment

[chenglou]

Fixed