Closes #50037

…ll-call

…to insert-full-call

This issue was introduced by #50552 and caused signature help to
misbehave while typing.

…tion-branch

Merge main into featuers/argument-completion

Merge main into features/argument-completion

Since we're only using this in snippets we generate ourselves, we can
just compute the value directly and insert that into the Snippet XML.

This takes advantage of the prior commit to simplify some state
management. When we were using snippet functions to populate each
parameter, it was necessary to ensure some state "survives" when we are
moving from one overload to the next. This is because there's some
reentrancy: the process of moving to a new overload would dismiss the
prior snippet, but it had to still be avialable before the call to
insert the new snippet returned. Now that the snippet is fully
pre-generated, that's not a requirement anymore; instead we can just
always clear state when one snippet is dismissed, and set it afterwards
again once the snippet is re-inserted. This removes the necessity of
having the "_preserveSymbols" flag, as well as removing the requirement
to call specific Clear() at various points when we were dismissing
sessions.

The other simplification is the list of methods that was stored once a
session began was only used to grab one thing: the name of the method
group. So just replace that with a string.

If the first overload displayed by signature help is a method with no
parameters, then we have a placeholder snippet field. If you type in
that snippet field, we would switch the active overload to something
else which would cause what you typed to disappear.

As long as an edit happens in the middle, the two methods can come from
different Compilations. If the methods are in source, they don't compare
the same.

Since we create snippets out of XML, ensure we don't mangle parameters
if they round-trip in some way.

…eaks

Argument completion tweaks

Only update snippet model on explicit selection