Document the types of ContentChanges

[AlexGustafsson]

The ContentChanges of DidChangeTextDocumentParams are of any type (interface{}). The documentation for the field does not specify what types it may hold, but the source code does. By moving the comment into the documentation for the field, users of the library may easily find what types the field may hold.

glsp/protocol_3_16/text-document-synchronization.go

Lines 77 to 92 in f4d3bef

	/**
	* The actual content changes. The content changes describe single state
	* changes to the document. So if there are two content changes c1 (at
	* array index 0) and c2 (at array index 1) for a document in state S then
	* c1 moves the document from S to S' and c2 from S' to S''. So c1 is
	* computed on the state S and c2 is computed on the state S'.
	*
	* To mirror the content of a document using change events use the following
	* approach:
	* - start with the same initial content
	* - apply the 'textDocument/didChange' notifications in the order you
	* receive them.
	* - apply the `TextDocumentContentChangeEvent`s in a single notification
	* in the order you receive them.
	*/
	ContentChanges []interface{} `json:"contentChanges"` // TextDocumentContentChangeEvent or TextDocumentContentChangeEventWhole

[tliron]

Well, this would be a problem, because this convention was used throughout and would have to be changed everywhere. The challenge is that I did my best to copy the comments "as is" -- the reason being that I am hoping that in the future we can generate GLSP code directly, or at least copy information directly from the spec source.

My thinking, also, is that because this is open source code it should be easy enough in your IDE to travel to the source and see it more exactly.

But perhaps there is a way to embed this in the main comment text, adding a special prefix or something else, e.g.:

	/**
	 * The actual content changes. The content changes describe single state
	 * changes to the document. So if there are two content changes c1 (at
	 * array index 0) and c2 (at array index 1) for a document in state S then
	 * c1 moves the document from S to S' and c2 from S' to S''. So c1 is
	 * computed on the state S and c2 is computed on the state S'.
	 *
	 * To mirror the content of a document using change events use the following
	 * approach:
	 * - start with the same initial content
	 * - apply the 'textDocument/didChange' notifications in the order you
	 *   receive them.
	 * - apply the `TextDocumentContentChangeEvent`s in a single notification
	 *   in the order you receive them.
	 *
	 * In Go: TextDocumentContentChangeEvent or TextDocumentContentChangeEventWhole	 
	 */
	ContentChanges []interface{} `json:"contentChanges"`

It would be a lot of work to change everything in GLSP to this convention. If someone wants to do it and send a PR, I will gladly accept.