`Position` values reported by the language server don't conform with the LSP spec

[SCWells72]

I'm in the process of integrating lsp-*.executable.jar via LSP and am finding that its responses seem to be out of compliance with the LSP spec. Specifically, it's reporting diagnostic positions like the following:

{
  "uri": "<filePath>",
  "diagnostics": [
    {
      "range": {
        "start": {
          "line": 0,
          "character": 207
        },
        "end": {
          "line": 0,
          "character": 212
        }
      },
      "severity": 3,
      "code": "SLDS_MOBILE_VALIDATION",
      "source": "SLDS",
      "message": "For best readability on mobile devices, consider using 14px or larger."
    }
  ]
}

where the values for character do technically correspond to the correct zero-based offsets in the file for the reported diagnostics, but the LSP spec for Position specifically states:

	/**
	 * If the character value is greater than the line length it defaults back
	 * to the line length.
	 */
	character: uinteger;

As a result, well-behaved LSP clients would not properly translate these reported positions to the corresponding row/column coordinates in the diagnosed file for character values greater than the length of the first line of the file.

And to be clear, it looks like VS Code should be a well-behaved client in this regard as its implementation of offsetAt(Position) does constrain the value to the length of the reported line number. That indicates to me that something in the SLDS Validator VS Code extension between the SLDS Validator language server and VS Code's LSP client is translating these out-of-spec responses into valid LSP Position values, though I haven't been able to confirm that concretely.

Apologies if I'm incorrect and these responses are in fact allowed and expected by LSP. If so, a pointer to the respective spec/doc would be greatly appreciated. If not, though, shouldn't these responses be changed to proper line/character pairs instead of the current 0/offset pairs that are currently being returned?

[SCWells72]

See #144 for some concrete examples of where and when this problem actually occurs. I'd also be fine if you wanted to merge this bug into that one since it is a superset of the issue reported here.