More general handling of `{` blocks in argument lists

We currently have special support for trailing { blocks and trailing lambdas. The goal is to prevent multi-line { blocks from causing expansion of arguments in cases like these:

with(data, {
  x + y
})

map(xs, function(x) {
  x + 1
})

The implementation is currently borrowed from Biome which has to deal with similar cases such as JS lambda functions (https://github.com/posit-dev/air/pull/4). It is rather complicated and involves a best fitting algorithm. It supposes that the { blocks are either leading (unused in Air) or trailing. However it's been pointed out to us that the same behaviour would still be desirable in non-trailing case, for instance if optional arguments are trailing:

expect_snapshot({
  ...
}, error = TRUE)

And in fact there are important classes of functions that rely on trailing arguments in this way, e.g. the base higer order functions like Find() or Reduce().

Find(function(x) {
  ...
}, xs, right = FALSE)

We could leverage Biome's leading group feature to implement this. But I think it's worth exploring the feasibility of a simpler approach where we'd simply treat all { blocks as "resetting" the line width. This would handle all blocks in the same manner, whether they are leading, trailing, or not. E.g. it'd be allowed to write the following without causing an expansion:

f(1, {
  ...
}, 2, 3, {
  ...
}, 4)

Expansion would still be possible by leveraging magic line breaks, e.g. in the above example you'd add a newline before 1 to force expansion, or remove it to request the flat layout.

Start by examining the existing handling for trailing { blocks and trailing lambdas, including the Biome-inspired best-fitting algorithm described in the issue. Test the listed non-trailing and multiple-block examples, then verify that magic line breaks still control expansion and that all block positions receive the intended layout behavior.