These can fail, so abort() just like glib does internally in case of OOM.
A special case is the pad allocation for autocompletion popups, which
can have excessively many lines. This is handled gracefully now
(the popup simply won't be displayed).

* It sends `null` instead of empty lists, even though this is violating the LSP specs.
* Filter out duplicates from the auto-completion lists.
  This may benefit other servers as well.
* ctags-lsp does not fuzzy search for workspace/symbol, so auto-completions
  aren't really a thing.
  The only special case is sending the empty string, which results in
  all symbols being returned. This can be slow, though.
* ctags-lsp does not support textDocument/references, so n:FT$ won't be supported.

* We use 23 now as the "id" for all JSON-RPC requests.
* Every message with a different "id" can be ignored,
  as it is a request, we haven't advertised to support.
  Alternatively, we should perhaps send an error response to
  unexpected requests?
* Fixes support for the ccls server which sends window/workDoneProgress/create
  even though I didn't advertise it.
  ccls cannot practically be used with FTsymbol$ though since it returns
  full declarations.
  You can perform a fuzzy symbol search, though.

Should fix Windows builds.

* The main interface is the `FT` command.
  `FT` was an undocumented Video TECO command for etags/ctags lookups.
  I don't want to exactly copy its interface, though.
* `FT` allows looking up symbol names,
  definitions and references.
* ctags will be supported via ctags-lsp.
  LSP support is more powerful though and works without
  regenerating TAGS files all the time.
  The LSP will also allow you to customize auto-completions
  using SciTECO itself (i.e. by writing a language server
  in SciTECO).
* For multiple results, `FT$` can be used to cycle through
  results - this should mimic repeated `S$` or `N$`.
* `:FT...$` does a fuzzy search. IMHO it's not important
  to return a status integer instead. `FT` will only
  really be used in interactive mode.
* Document synchronization is supported via hooks from
  ring.c and via Scintilla notifications.
* Currently, the LSP communication is based on blocking
  GIOChannels. This means that a misbehaving hanging
  server could "lock up" the entire editor (FIXME).
  Only on ncurses you can always kill the subprocess by
  pressing CTRL+C.
  We need helper functions in spawn.c to read and write
  with interruptions.
* The textDocument/didChange notification transmits
  not only all edits, but all files' contents as well
  during initial synchronization.
  Therefore it is optimized to write and JSON-escape
  data without copying them around in memory and without
  destroying the buffer gap.
* Use $SCITECO_LSP to configure the language server.
  You can also use `tee` to capture stdin and stdout.
  Perhaps $SCITECO_LSP should be saved in .teco_session,
  so you can change it between projects?
* $SCITECO_LSP_ROOT is used to point to the project's
  root directory. session.tes will set it up automatically.

This fixes insertion of strings containing ^, ^P, ^Q, ^R, ^V, ^W, ^E.
It mainly affects Q-Register specification auto-completions, but filenames
could theoretically also contain such special characters.

* This has been broken for some time, but it didn't crash in v2.5.2.
* Even when it did not crash, the search just failed.
  In TECO-11 (judging by TECOC), we must throw an error, though.
  Video TECO on the other hand always succeeds in such cases.
* Added test case

If you had a partial success during interactive searching, dot would be
left at that position since the failure handling only reset via SCI_GOTOPOS.
This is now fixed by restoring the initial dot in glyphs as well.
All existing occurrences of "dot" have been renamed to "pos" for consistency.
(Nowadays, "dot" should be reserved for glyph positions since this is what
`.` returns. Especially if both kinds of positions are used in the same code.)

A test case has been added.

This has been broken since 685507922b0b75da5935076395a5b1ec1ef58356.

* Atomics are much cheaper than mutexes for such rarely contented
  fields, but they are still much slower than plain arithmetics.
* For realloc(), we'd expect relatively small changes between calls
  which means that the chunk's usable size probably won't change.
  Therefore it makes sense to check whether we'd get a zero addition
  to teco_memory_usage.
* We will now have at most one atomic add in realloc() instead of
  always 2 atomic operations.

It can also be useful for spawning $SCITECO_CLIPBOARD_SET/GET processes (currently via popen())
and for launching language servers.