Avoid list absorbtion when appended by two more non-list-literal expressions

[ShamrockLee]

Description

"Absorption" is an "an alternative layout" that reduces indentation level, according to NixOS/rfcs#166. That is, the specification allows such "alternative" alongside the indent-after-newline right-hand-side style.

Given a chain of evaluated-to-list expressions chained by list concatenation operators (++) consisting of at least one of which is a multi-line literal list and two adjacent non-list-literal expressions, if the multi-line list literal gets absorbed, the adjacent non-list-literal terms will be squashed into the same line, producing a long, hard-to-read, and git-diff-unfriendly line of code.

Current implementation of nixfmt sometimes perform the above-mentioned absoption. In my opinion, such behavior should be avoided.

Small example input

{
  buildInputs = [
    "ee"
    "fff"
    "gggggggg"
    "hhh"
    "iiiii"
    "jjjjj"
    "kkkkkkkkkkk"
  ]
  ++ lib.optional true "lllll-lllll"
  ++ lib.optional false "mmmmmmmm"
  ;
}

Expected output

{
  buildInputs =
    [
      "ee"
      "fff"
      "gggggggg"
      "hhh"
      "iiiii"
      "jjjjj"
      "kkkkkkkkkkk"
    ]
    ++ lib.optional true "lllll-lllll"
    ++ lib.optional false "mmmmmmmm";
}

Actual output

{
  buildInputs = [
    "ee" # To patch /bin/sh shebangs.
    "fff"
    "gggggggg"
    "hhh"
    "iiiii"
    "jjjjj"
    "kkkkkkkkkkk" # Required at build time by SingularityCE
  ] ++ lib.optional true "lllll-lllll" ++ lib.optional false "mmmmmmmm";
}

[piegamesde]

Hotfix in #269. The rule for this special case is that anything goes on the RHS of the ++/// as long as it fits onto the rest of the line. This probably should be reworked in a more structured and stricter way.

For now, I've simply excluded the RHS to be another operation in order to expand operation chains as desired. I think that for now this should be sufficient, I don't think there are many other scenarios where people might run into this.