cc @amesgen, just because you did the ghc-lib-parser-9.2 upgrade

Can you come up with an example that would demonstrate the difference between the current behavior and the behavior with sitcc added?

so I found some differences with do-blocks in tuple sections:

-- without sitcc
x =
  [ (do
      x <- asdf
      return x,)
  ]
x =
  [ (do
      x <- asdf
      return x,do
      x <- asdf2
      return x,)
  ]

-- with sitcc
x =
  [ (do
       x <- asdf
       return x,)
  ]
x =
  [ (do
       x <- asdf
       return x,do
                  x <- asdf2
                  return x,)
  ]

without sitcc, do blocks in a tuple section don't know that they're in a tuple; they're indented only once (in the list context) as opposed to twice (in the list + tuple context). In the second case, I'm actually surprised that the first isn't a parse error, since I thought x <- asdf2 needs to be to the right of the do keyword, but GHC accepts it. Regardless, I think the case with sitcc is better than the case without (although both should be fixed to add the appropriate space/newline before the do).

This only comes up with tuple sections because commaDel adds a breakpoint before, which seems to handle the missing sitcc logic. So it might not be that big of a deal (who does tuple sections with multiline blocks?), but I'd argue that:

1. adding sitcc does the least-unexpected thing in the uncommon case
2. adding sitcc does nothing in the common case
3. adding sitcc fixes an issue in the downstream fourmolu project

I know (3) probably doesn't matter to you, but in combination with (1), i don't see any reason not to do it, and it has a nice side benefit of helping downstream. plus, i suspect that if ormolu changes something around styling tuples here, this sitcc will be needed, so this is also future-proofing

Thanks!