Use byteidx()/utf16idx() for correct UTF-16 position conversion

[mattn]

Summary

• Use byteidx(str, idx, v:true) and utf16idx(str, byteidx) for LSP position conversion when available (Vim 9.0.1485+)
• LSP uses UTF-16 code unit offsets, but the current strcharpart()/strchars() counts Unicode codepoints, which is incorrect for characters outside the BMP (e.g. emoji with surrogate pairs)
• Falls back to existing codepoint-based conversion on older Vim and Neovim

Changed files

• autoload/lsp/utils/position.vim: s:to_col() and s:to_char() now use UTF-16 aware builtins
• autoload/lsp/utils.vim: lsp#utils#to_char() likewise

Test plan

• Verify LSP go-to-definition, hover, completion work correctly with ASCII, CJK, and emoji (BMP-external) characters
• Verify no regression on Neovim (falls back to existing behavior)

[mattn]

Benchmark results

iterations: 100000
short : 48 bytes
long  : 303 bytes
vlong : 2903 bytes

to_col  short        old: 0.3346  new: 0.2818  (1.2x)
to_col  long         old: 0.3139  new: 0.3479  (0.9x)
to_col  vlong        old: 0.4681  new: 1.0679  (0.4x)

to_char short        old: 0.2833  new: 0.2712  (1.0x)
to_char long         old: 0.3356  new: 0.3827  (0.9x)
to_char vlong        old: 0.5920  new: 1.9010  (0.3x)

Short strings are slightly faster, but long strings are slower due to byteidx() calling ptr2len() twice per iteration in UTF-16 mode (once for surrogate pair check, once for advancing). This is a Vim core inefficiency that should be fixed separately.

The primary benefit of this PR is correctness: proper UTF-16 code unit handling for characters outside the BMP (emoji with surrogate pairs), which strcharpart()/strchars() (codepoint-based) cannot handle correctly.