fix: Correctly set the span of the proc_macro crate's Group delimiters

[ChayimFriedman2]

Previously only the open delimiter's span was set, and this caused... weird problems.

Probably fixes (don't close!) #18471, and possibly also #19834. The problem is that we only had the span of the closing parentheses of the call, and for descending attributes we look at the first and last token, but we couldn't find the last token (the closing paren) in the macro. However, there could be other problems too, so I don't want to close them yet before we verify it works (it's hard to test proc macro server changes).

Perhaps it's worth reconsidering our strategy for descending into attribute macros, especially given that when users create their own Groups they have no way of setting each delimiter span separately, only for both.

[ChayimFriedman2]

I try to locate the origin of this code but there was some mess with history due to syncs so I couldn't...

[Veykril]

I try to locate the origin of this code but there was some mess with history due to syncs so I couldn't...

I implemented that logic I believe (or at least parts of it), but there was no concrete reasoning as to why we do the thing the way we do here iirc

Perhaps it's worth reconsidering our strategy for descending into attribute macros, especially given that when users create their own Groups they have no way of setting each delimiter span separately, only for both.

That's a good point, definitely worth revisiting our strategy here.

Also note that some decisions for this were shaped by our token tree model back then. We used to only encode a single TokenId for the delimiter pair (back when we used TokenId), which is nowadays fixed.