Implement "leading hole hugging" behavior

[DavisVaughan]

Closes #32

Two main changes:

• Implemented hugging for what I call "leading holes", which greatly improves data.table formatting where its common to have a leading , hole for an empty i expression (explained below)
• Was forced to sit down and confront comment handling for holes, something I had some TODO comments in there for and knew we'd have to do eventually

Leading holes

Imagine you have this data.table expression, and you want to expand it over multiple lines

dt2 = dt[, .(total_value_received = sum(price * count)), by = "product_id"]

Before this PR, your only option was to hit enter between the [ and the first , and you'd get this:

dt2 = dt[
  , 
  .(total_value_received = sum(price * count)), 
  by = "product_id"
]

Not great!

After this PR, the "hole" [<here>, is considered a "leading hole". Leading holes "hug" tightly to the opening [ token no matter what, so you get this:

dt2 = dt[,
  .(total_value_received = sum(price * count)),
  by = "product_id"
]

So much nicer! This is pretty common with data.table users, and even chains nicely:

dt2 = ProductReceived[
  Products,
  on = c("product_id" = "id"),
][,
  .(total_value_received = sum(price * count)),
  by = "product_id"
]

Note that you can have any number of repeated leading ,s, they all get aggregated together as a set of leading holes.

If there is a comment within a hole, it is no longer a candidate to be a "leading hole" and is instead considered as a normal argument, subject to typical "fully expanded" rules

dt2 = dt[
	# no longer a leading hole
	,
	.(total_value_received = sum(price * count)),
	by = "product_id"
]

To be clear, only holes up front can be leading holes. Trailing and intermediate holes still fully break, like this

dt2 = dt[,
	.(total_value_received = sum(price * count)),
	,
	by = "product_id"
]

I think this is good behavior because these holes are relatively "weird" and the extra spacing makes them very visible.

Leading holes and user requested line breaks

We treat leading holes as roughly invisible when detecting if the user requested a line break. With the example from before:

dt2 = dt[, .(total_value_received = sum(price * count)), by = "product_id"]

You can actually add a newline before or after that , and it will be treated like a user line break. The , will snap back to hugging the [ tightly but the arguments will get expanded. The principle for user requested expansion here is:

The user added a line break anywhere before the first non-hole argument in a call

This seems to result in the least surprising behavior.

[DavisVaughan]

Holes and comments are quite tricky to think about. In the following example:

fn(
  a, # comment
  ,
  b
)

you might think the formatter assumes the hole is here

fn(
  a, # comment
  <hole>,
  b
)

That would make # comment trailing on a automatically with the Default comment placement behavior.

But that isn't what happens! Instead, holes are placed "eagerly" like this:

fn(
  a,<hole># comment
  ,
  b
)

This causes # comment to be a trailing comment on the hole by default. This trailing comment behavior ALWAYS happens with holes, and is something we exploit as it simplifies our hole comment handling. It is also how the biome group handles array hole comments, so I feel good about it:
https://github.com/biomejs/biome/blob/66458a12a048b0e686b242d9d4dd0f0e90d1f92a/crates/biome_js_formatter/src/comments.rs#L241-L242

[DavisVaughan]

take_while_ref() is a neat feature from itertools that allows you to, say, take the first n elements out of an iterator without consuming the iterator, which allows you to then do two separate collect() calls to split the iterator results into two vectors.