LSP: Validate responses against client capabilities

There are a number of places where responses from the LSP should be altered based on client and server support. Responses for things like textDocument/rename that return a WorkspaceEdit are a good example of this:

export interface WorkspaceEdit {
	/**
	 * Holds changes to existing resources.
	 */
	changes?: { [uri: string]: TextEdit[]; };
        /**
	 * Depending on the client capability `workspace.workspaceEdit.resourceOperations` document changes
	 * are either an array of `TextDocumentEdit`s to express changes to n different text documents
	 * where each text document edit addresses a specific version of a text document. Or it can contain
	 * above `TextDocumentEdit`s mixed with create, rename and delete file / folder operations.
	 *
	 * Whether a client supports versioned document edits is expressed via
	 * `workspace.workspaceEdit.documentChanges` client capability.
	 *
	 * If a client neither supports `documentChanges` nor `workspace.workspaceEdit.resourceOperations` then
	 * only plain `TextEdit`s using the `changes` property are supported.
	 */
	documentChanges?: (TextDocumentEdit[] | (TextDocumentEdit | CreateFile | RenameFile | DeleteFile)[]);
}

Start by locating the LSP response handling for textDocument/rename and WorkspaceEdit, then inspect how client capabilities are represented. Map the other response types that need capability-based adaptation; done means unsupported WorkspaceEdit features are converted or omitted according to the client's capabilities.