Add a "data" field to CompletionList for round-tripping data from the server when resolving completion items

One of the big issues that comes up periodically from LSP clients is how much data is in the textDocument/completion payload when auto-import completions is enabled (that is, we include symbols that are not imported into the current scope, and automatically insert imports for them if they are selected).

Part of the reason this is huge is that we need to round-trip some data to the server in order to be able to build everything we need in the resolve call. We do this using the data field on CompletionItem. Here's an example of some completion items:

	{
		"data": {
			"rLength": 7,
			"rOffset": 848,
			"displayUri": "package:flutter/material.dart",
			"libId": 598,
			"offset": 855,
			"file": "/Users/dannytuppeny/Projects/MyProjectThing/lib/view/page/setting.dart"
		},
		"sortText": "999993",
		"kind": 7,
		"label": "SliverAnimatedList"
	},
	{
		"data": {
			"rLength": 7,
			"rOffset": 848,
			"displayUri": "package:flutter/material.dart",
			"libId": 598,
			"offset": 855,
			"file": "/Users/dannytuppeny/Projects/MyProjectThing/lib/view/page/setting.dart"
		},
		"sortText": "999993",
		"kind": 13,
		"label": "GrowthDirection"
	},
	{
		"data": {
			"rLength": 7,
			"rOffset": 848,
			"displayUri": "package:flutter/material.dart",
			"libId": 598,
			"offset": 855,
			"file": "/Users/dannytuppeny/Projects/MyProjectThing/lib/view/page/setting.dart"
		},
		"sortText": "999993",
		"detail": "(BuildContext context, T value, Widget child) → Widget",
		"kind": 7,
		"label": "ValueWidgetBuilder"
	},
	{
		"data": {
			"rLength": 7,
			"rOffset": 848,
			"displayUri": "package:flutter/material.dart",
			"libId": 598,
			"offset": 855,
			"file": "/Users/dannytuppeny/Projects/MyProjectThing/lib/view/page/setting.dart"
		},
		"sortText": "999993",
		"kind": 7,
		"label": "Texture"
	},

You'll notice here that every completion item (of which there may be a few thousands) has the same data attached to it:

		"data": {
			"rLength": 7,
			"rOffset": 848,
			"displayUri": "package:flutter/material.dart",
			"libId": 598,
			"offset": 855,
			"file": "/Users/dannytuppeny/Projects/MyProjectThing/lib/view/page/setting.dart"
		},

The data here is much larger than the rest of the info for each completion item. This means over 50% of the payload is redundant.

It would be nice if we could include some data on the CompletionList which gets merged into data (or supplied in addition to) on a resolve call, then we could eliminate half of the payload (and along with it, some of them time spent deserialising all of this).

Another option would be for us to stash this on the server and just send an ID back - however without making some assumptions about when it's save to clear up, this could cause issues... If LSP stated that resolve can never be called for a completion item that wasn't in the last set of results, that might fix that.

Start with the protocol definitions for CompletionList and CompletionItem, then review the 18-comment discussion and the existing resolve flow. Determine the precise merge or supplementary-data semantics and the lifetime rules for data returned by completion requests. Done means the protocol specifies a workable way to round-trip shared data without requiring every completion item to repeat it.