Introduce completion item collapse for method overloads

[hopehadfield]

Fixes #2282

Before:

After:

The list of methods should ideally be displayed in signature help after selecting the completion item, though there exists a bug in which this isn't always the case.

[rgrunber]

A few oddities I noticed :

• append & format show up (when typing out the first p and filtering to print) because their filterText includes PrintStream, but we now hide that (in favour of the "overloads .." section in this mode. It's something to think about. (ignore the weird bold text, that's a separate client issue)

• When this feature is enabled, and combined with java.completion.guessMethodArguments, there is a slight difference in behaviour of which constructor gets displayed. When guessing is off, it seems like it's always the first (no-arg?) that gets displayed so that's what gets activated for signature help. When it's parameter/best-guess, it's often one of the 1-arg (or greater) options. Is this expected ?

[rgrunber]

Did you do this because you noticed that the regular detail field was being set for completion items that were using the labelDetails field, so you tried to preserve that behaviour for regular methods ? But opted to eliminate it for collapsed types ?

According to https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#completionItem I don't really see anything that says label details make the regular detail field obsolete so I guess we opted to keep it around.

[hopehadfield]

Yes, I didn't want to alter the behaviour for non-collapsed proposals, but removed it for the collapsed proposals because it contained proposal details that would only be related to one of multiple collapsed proposals. There was nothing relevant to include in the field so I just left it as null.

[rgrunber]

Yeah, I guess that's fine. Also skipDetail seems to be true only when a type should be collapsed & is not a constructor so you probably could have used the exact same check, or used skipDetail even earlier to avoid the other check.

I guess I was aiming towards moving the if (!skipDetail) block into the block above, but because it's used in 2/4 cases, might as well save space like we are now.