Fix completion item label condition

[soywod]

Related to #583.

When fuzzy completion is used, the wrong label is used when validating a completion item. For example, rust-analyzer could return remove_dir (alias rmdir) as a label, but remove_dir as next text (this late one should be used instead of the first one).

I'm not sure to understand why this section is restricted to non-fuzzy completion value matcher only. The label condition (either item.textEdit.newText, item.insertText or item.label) is useful no matter the completion matcher.

[berggeist]

I don't know why fuzzy matching is excluded here.
I would guess that text editing by applying the range does not play well in combination with fuzzy matching. But this is only a guess.
By the way, it has been introduced by @andlrc with his pull request: #178
Maybe @andlrc can enlighten us here.

Instead of removing the special handling of fuzzy matching, an additonal fallback branch might also help. Otherwise the language server specifiation is not fulfilled, which mandates CompletionItem.label shall only be used if there is neither CompletionItem.insertText nor CompletionItem.textEdit.

    if item->has_key('textEdit') &&
	lspOpts.completionMatcherValue != opt.COMPLETIONMATCHER_FUZZY

...
new fallback branch:

    elseif item->has_key('textEdit')
       d.word = item.textEdit.newText

    elseif item->has_key('insertText')
      d.word = item.insertText
    else
      d.word = item.label
    endif

[soywod]

elseif item->has_key('textEdit') would still prevent fuzzy completion to get the right label. Let's wait for more context about the condition.