Fix modifier order for class member completions

[gabritto]

Fixes #46568 (third item).

This PR makes it so that, when the user has already typed in some modifiers (e.g. abstract, override), we replace those already present modifiers, and then insert the class member signature (which will contain the already present modifiers). Before, we were not replacing the already present modifier, and instead just adding the new modifiers after those, causing the modifier order to be wrong in some cases (e.g. if the user had already typed abstract but we needed to insert private along with the signature, we'd get abstract private foo, but the correct order is private abstract foo).

I also removed replacementSpans of length 0 from some fourslash tests, as those are useless.

[gabritto]

@andrewbranch on the useless replacement spans, I'm not sure what was happening before that led me to add them, but looking at the code now, it looks like as of #42013 we don't check the actual replacement span if the expected replacement span has 0 length. Why did we do this? I also wonder if it shouldn't be the opposite, as in, if the actual replacement span has length 0, we don't need to specify a expected replacement span.

[andrewbranch]

On the replacement spans, I probably intended the opposite, but in hindsight I think replacement spans are such an important piece of info that they should probably always be checked to be an exact match, even if it wasn’t provided in the expected.

[andrewbranch]

Although if that requires updating a bunch of tests, maybe not worth enforcing that now.