Fixes #65435

Fixes #65435

Use modes.SignatureHelp as source of truth for activeSignature

Use the model to track state and active parameter instead of tracking this in the widget itself. This enforces a cleaner boundary between model and view

Fixes #64216

Fixes #58492

**Bug**
If multiple triggers come in at the same time, we currently lose the re-trigger state. This is caused by each trigger canceling the existing request. The first one is treated as a re-trigger, but all subsquent triggers look like fresh triggers

**Fix**
Move the cancelation into the actual trigger body.

Make sure we a trigger always cancels any pending requests, even if the model is now invalid

Try to avoid using as much state.

#54972

Instead of having a generic `Retrigger` reason, add a new field on the `SignatureHelpContext` that tracks if this was a retrigger or not. This allows retrigger for all the different trigger reasons, including invoke.

Replace the old `Retriggger` trigger reason with `ContentChange` which tracks cursor movement and text updates.

update internal API to allow parameter label to be an offset-range of its the signature label, #56337

Introduces the concept of a re-trigger character to the signature help provider. This is a seperate set of characters that are registered with the provider. Typing a retrigger character fires a new signature help request if signature help is already showing.

#54972

We compile using the alwaysStrict flag so these directives are not needed

* Initial work on signature help context

Fixes #54972

Adds `SignatureHelpContext`. This tells providers why signature help was requested

TODO:

- [ ] Better understand semantics of retrigger. Should `retrigger` be an flag instead of a `triggerReason`?
- [ ]  Fix skipped test
- [ ] Add more tests for trigger reasons / trigger characters

* Fix unit test

* Make sure we retrigger sig help if it is already showing

* Add test for dismiss and re-invoke

* Extract some constants

* Extract createMockEditor

Fixes #48237

Fixes #48758