Problem:  Inefficient use of ga_concat()
Solution: Use ga_concat_len() when the length is already known to avoid
          use of strlen() (John Marriott).

closes: vim/vim#19422

https://github.com/vim/vim/commit/ed202035b1904c84d92adb76d7e1a95b7540e048

Co-authored-by: John Marriott <basilisk@internode.on.net>
Co-authored-by: Hirohito Higashi <h.east.727@gmail.com>

Problem:  Inefficient use of ga_concat()
Solution: Use ga_concat_len() when the length is already known to avoid
          use of strlen() (John Marriott).

Additionally the following changes are done:
os_unix.c:
- in function `socket_server_list_sockets()` use a `string_T` for the
  strings `buf` and `path` for use in `ga_concat_len()`
  and drop un-needed variable `dir`.

quickfix.c:
- in function `qf_jump_print_msg()` use a `string_T` for the string
  `IObuff` for use in `ga_concat_len()`.
- in function `qf_range_text()` use a `string_T` for the string `buf`
  for use in `ga_concat_len()`.

register.c:
- simplify function `execreg_line_continuation()`.

terminal.c:
- in function `read_dump_file()` use a `string_T` for the
  string `prev_char` for use in `ga_concat_len()`.

tuple.c:
- in function `tuple_join_inner()` use a `string_T` for the
  string `s` for use in `ga_concat_len()`. Also, change local struct
  `join_T` to use `string_T`.

vim9type.c:
- in functions `type_name_tuple()` and `type_name_func()`
  use a `string_T` for the string `arg_type` for use in
  `ga_concat_len()`.

closes: vim/vim#19038

https://github.com/vim/vim/commit/a7e671fbb9fa2af9ad6c4ba9a7a881df431cd02b

Skip tuple.

Co-authored-by: John Marriott <basilisk@internode.on.net>

Problem:  inefficient use of ga_concat()
Solution: Use ga_concat_len() when length is known.
          (John Marriott)

closes: vim/vim#19027

https://github.com/vim/vim/commit/32b801abc35b03e6f88021b29c24dd2411f7a065

Co-authored-by: John Marriott <basilisk@internode.on.net>

Problem:    Converting a funcref to a string leaves out "g:", causing the
            meaning of the name depending on the context.
Solution:   Prepend "g:" for a global function.

https://github.com/vim/vim/commit/c4ec338fb80ebfb5d631f0718fdd1a1c04d9ed82

Co-authored-by: Bram Moolenaar <Bram@vim.org>
Co-authored-by: Jan Edmund Lazo <jan.lazo@mail.utoronto.ca>

These are not needed after #35129 but making uncrustify still play nice
with them was a bit tricky.

Unfortunately `uncrustify --update-config-with-doc` breaks strings
with backslashes. This issue has been reported upstream,
and in the meanwhile auto-update on every single run has been disabled.

This also makes shada reading slightly faster due to avoiding
some copying and allocation.

Use keysets to drive decoding of msgpack maps for shada entries.

Now msgpack-c is never used for packing. The real fun part will be
replacing it for unpacking.

This is a breaking change which will make refactor of typval and shada
code a lot easier. In particular, code that would use or check for
v:msgpack_types.binary in the wild would be broken. This appears to be
rarely used in existing plugins.

Also some cases where v:msgpack_type.string would be used to represent a
binary string of "string" type, we use a BLOB instead, which is
vimscripts native type for binary blobs, and already was used for BIN
formats when necessary.

msgpackdump(msgpackparse(data)) no longer preserves the distinction
of BIN and STR strings. This is very common behavior for
language-specific msgpack bindings. Nvim uses msgpack as a tool to
serialize its data. Nvim is not a tool to bit-perfectly manipulate
arbitrary msgpack data out in the wild.

The changed tests should indicate how behavior changes in various edge
cases.

Step towords completely eliminating msgpack_packer.