Formatting of selections in function arguments does not agree with RFC 166

[oxalica]

Description

Related: #153

I'm trying to apply RFC 166 style on rust-overlay and noticed this weird formatting.

Small example input

{
  rust-channel-of-version = assertEq (rustChannelOf { channel = "1.48.0"; }).rustc stable."1.48.0".rustc;
}

Expected output

{
  rust-channel-of-version = assertEq (rustChannelOf { channel = "1.48.0"; }).rustc
    stable."1.48.0".rustc;
}

Actual output

{
  rust-channel-of-version = assertEq (rustChannelOf { channel = "1.48.0"; })
    .rustc stable."1.48.0".rustc;
}

It splits the selection in the first argument, but does not put the second arguments on a newline, which is really confusing to me. It looks like (assertEq (..)).rustc instead of assertEq ((..).rustc)

Rationale

As described in RFC 166:

Function application

• In a function application chain, the first element is treated as the "function" and the remaining ones as "arguments".
• As many arguments as possible must be fit onto the first line.
• If there is at most one multi-line argument that can be absorbed and all other arguments before/after fit onto a single line respectively, then that multi-line argument is absorbed.

Thus the first argument should be inlined as a whole, and the second argument should be put on a new line (otherwise it would exceed the max width 100).

[infinisil]

Looking into this. So far just a minimal reproducer with nixfmt -w 8:

Input:

a (b).c d."e"

Output:

a (b)
  .c d."e"

[infinisil]

Trying to fix it with #249