Additional requests for incomplete completion lists should pass `completionTriggerKind=TriggerForIncompleteCompletions`

When a LS marks the list of completions as incomplete, the spec says that the client must send further textDocument/completion requests for each additionally typed character, see doc of isIncomplete. The spec also says, that further requests should use CompletionTriggerKind.TriggerForIncompleteCompletions. However, LSP4E currently does not honor this part of the spec.

In our use-case, with the basedpyright LS, this leads to the behavior, that the server keeps marking the response as incomplete, because it will only mark the third subsequent completion result as complete. This leads to the annoying behavior, that the completion popup is reopened constantly (which also triggers #1448)

I tried to solve this, but wasn't able to get anywhere. But I thought I document my findings, in case someone else wants to have a go at it.

• We need to know whether a user started a new completion session, i.e. by pressing ctrl+space (use CompletionTriggerKind.Invoked) or typing a trigger character (use CompletionTriggerKind.TriggerCharacter) or if he kept typing with the completion window still open (and the list being incomplete, -> use CompletionTriggerKind.TriggerForIncompleteCompletions)
• It's possible to implement a org.eclipse.jface.text.contentassist.ICompletionListener. This would allow us to know whether a new completion session was started, in which case we could send CompletionTriggerKind.Invoked or CompletionTriggerKind.TriggerCharacter for the first request and TriggerForIncompleteCompletions for further requests, if the returned list was incomplete.
• Eclipse (i.e. org.eclipse.jface.text.contentassist) only computes the completions on the first typed character and afterwards uses org.eclipse.jface.text.contentassist.ICompletionProposalExtension2.validate(IDocument, int, DocumentEvent) to filter the resulting list with respect to any further typed characters. The only exception to this is, when all Proposal say they are invalid, then another computation is triggered. LSP4E currently uses this to trick Eclipse into another computation, by saying that completions which are incomplete are only valid for the offset at which the first request was sent. However, this causes the completion popup to be closed and re-openend after each character. This also causes a restart of the completion session, which makes our ICompletionListener useless, because we can't distinguish, if the user actually started a new completion session, or if it was just the completion proposal popup which decided to close and reopen.

I think we would need to make some changes (or bug fixes) to the org.eclipse.jface.text.contentassist API, but that is probably quite the hassle.

Read the completion handling involving org.eclipse.jface.text.contentassist.ICompletionListener and ICompletionProposalExtension2, then compare it with CompletionTriggerKind and the LSP completion specification. Determine how a completion session can distinguish initial requests from subsequent incomplete-list requests without reopening the popup. Done means additional requests use TriggerForIncompleteCompletions while preserving normal session behavior.