Added constraints to ParameterInformation.label break possible use cases

Beyond adding support for inclusive start and exclusive end offsets to spec, commit 3854f1c added additional constraints to ParameterInformation.label when in string form, which can preclude neat functionality for users:

Note: A label of type string must be a substring of its containing signature label.

For example, before, compliant client and servers could take advantage of not having such limitation to provide terser prototype form on SignatureInformation.label, while providing full parameter types on each ParameterInformation.label. Types can be rather long, so having full form just for active parameter that clients can pick from parameters, while having short form of the rest (from SignatureInformation.label), can provide ideal UX and better language support (see Go example bellow).

Beyond that, the current addition require clients to inform the capability of reading labels as offsets (otherwise it could potentially break clients), while the following doesn't need it.

Proposal

To solve this, while still have the added constraints available, I think the best protocol would not change ParameterInformation.label from string to string | [number, number] (making a label work as label or as highlighting), but instead add a specific field to convey a highlight over SignatureInformation.label:

label: string,                 // unconstrained label
highlight?: [number, number],  // "highlight" over SignatureInformation.label

This keep intentions for fields (ParameterInformation) and sub-fields (label) clear, while nor the previous or the current state is clear at all. And also gives room for the potential use-cases referred in this thread, which could in fact be in use already.

In this proposal label just means to be a textual label, as it could have always been interpreted before. It is not to mean label whose job is highlighting, but when in string form (which is the usual form of labels) is unable to do that job correctly (1. there could be multiple matches, int matches in 3 places in the int foo(int, int) signature; 2. it's misnamed "label").

highlight is a proper highlight (correctly named), and not an option to string, so that it can do its job correctly as a properly indexed [number, number] sub-string view, and never fail at that (no multiple matches).

This is nice because beyond adding an always correct highlighting, the text for label is free from being identical to the highlight, to keep doing its job as a simple label on its own. It can't also break clients. There's no need to announce capability.

Better language support

For example, with this proposal we could have for Go a foo(a, b: int) -> int signature label, with non matching a: int and b: int parameter labels (or simply int for each), with highlight on a or b in the signature. It's impossible to do that with the current state.

No file or test is named in the issue. Start by reviewing the ParameterInformation and SignatureInformation protocol definitions against the proposal. Done means the label and highlight semantics, along with client compatibility implications, are resolved.