fuzzymatch speed up

- [x] VIM 中用原生matchfuzzy函数代替自定义实现
- [x] 所有插件的 completor 在确保 directory 正确返回 false 的情况下全部异步掉，确保 firstCompleteRender 等待的时间尽可能的短，副作用是 firstCompleteRender 出来后，哪个插件的 completor 快就先显示哪个，速度参差不齐时会明显感知到菜单在不断的刷新变化
- [x] snip body 的获取和 sha256 函数优先不走 python
- [x] 首次匹配的 easycomplete#util#GetVimCompletionItems() 函数耗时最久，造成可肉眼感知的卡顿，一个是函数本身的性能优化，另一个是要减少 lsp 返回的 result 的数量，nim 就给了全量返回，需要先做一层过滤。

比如 snip 的 completor 逻辑修改成：

```diff
function! easycomplete#sources#snips#completor(opt, ctx)
if strlen(l:typing) == 0
call easycomplete#complete(a:opt['name'], a:ctx, a:ctx['startcol'], [])
return v:true
endif
call easycomplete#util#AsyncRun(function('s:CompleteHandler'),
\ [l:typing, a:opt['name'], a:ctx, a:ctx['startcol']], 1)
+ call easycomplete#complete(a:opt['name'], a:ctx, a:ctx['startcol'], [])
return v:true
endfunction
```

Start with easycomplete#util#GetVimCompletionItems(), firstCompleteRender, and the snips completor shown in the issue. Review the listed AsyncRun path and LSP result filtering, then check whether the completed checklist leaves a specific reproducible slowdown or benchmark. Done requires a clearly measured completion-speed improvement without breaking the stated false-return and rendering behavior.

Written by the indexing model from the issue text.