refactor(sign): move legacy signs to extmarks

Problem:  The legacy signlist data structures and associated functions are
          redundant since the introduction of extmark signs.
Solution: Store signs defined through the legacy commands in a hashmap, placed
          signs in the extmark tree. Replace signlist associated functions.

Usage of the legacy sign commands should yield no change in behavior with the
exception of:
  - "orphaned signs" are now always removed when the line it is placed on is
    deleted. This used to depend on the value of 'signcolumn'.
  - It is no longer possible to place multiple signs with the same identifier
    in a single group on multiple lines. This will now move the sign instead.

Moreover, both signs placed through the legacy sign commands and through
|nvim_buf_set_extmark()|:
  - Will show up in both |sign-place| and |nvim_buf_get_extmarks()|.
  - Are displayed by increasing sign identifier, left to right.
    Extmark signs used to be ordered decreasingly as opposed to legacy signs.

Problem: buffer text with composing chars are converted from UTF-8
to an array of up to seven UTF-32 values and then converted back
to UTF-8 strings.

Solution: Convert buffer text directly to UTF-8 based schar_T values.

The limit of the text size is now in schar_T bytes, which is currently
31+1 but easily could be raised as it no longer multiplies the size
of the entire screen grid when not used, the full size is only required
for temporary scratch buffers.

Also does some general cleanup to win_line text handling, which was
unnecessarily complicated due to multibyte rendering being an "opt-in"
feature long ago. Nowadays, a char is just a char, regardless if it consists
of one ASCII byte or multiple bytes.

The 'termsync' option enables a mode (provided the underlying terminal
supports it) where all screen updates during a redraw cycle are buffered
and drawn together when the redraw is complete. This eliminates tearing
or flickering in cases where Nvim redraws slower than the terminal
redraws the screen.

Problem:  recursive callback may cause issues on some archs
Solution: Decrease the limit drastically to 20

Recursive callback limit causes problems on some architectures

Since commit 47510f3d6598a1218958c03ed11337a43b73f48d we have a test
that causes a recursive popup callback function to be executed. However
it seems the current limit of 'maxfuncdepth' option value is still too
recursive for some 32bit architectures (e.g. 32bit ARM).

So instead of allowing a default limit of 100 (default value for
'maxfuncdepth'), let's reduce this limit to 20. I don't think there is a
use case where one would need such a high recursive callback limit and a
limit of 20 seems reasonable (although it is currently hard-coded).

closes: vim/vim#13495
closes: vim/vim#13502

https://github.com/vim/vim/commit/2076463e383901cef44685aaf4b63e4306444f9e

Co-authored-by: Christian Brabandt <cb@256bit.org>

runtime(doc): clarify when formatoptions applies

closes: vim/vim#13503

https://github.com/vim/vim/commit/1b08d2cd0789fd9aaae148a64ff46342730022d7

Co-authored-by: Christian Brabandt <cb@256bit.org>

Problem:  statusline may look different than expected
Solution: do not check for highlighting of stl and stlnc characters

statusline fillchar may be different than expected

If the highlighting group for the statusline for the current window
|hl-StatusLine| or the non-current window |hl-StatusLineNC| are cleared
(or do not differ from each other), than Vim will use the hard-coded
fallback values '^' (for the non-current windows) or '=' (for the
current window).  I believe this was done, to make sure the statusline
will always be visible and be distinguishable from the rest of the
window.

However, this may be unexpected, if a user explicitly defined those
fillchar characters just to notice that those values are then not used
by Vim.

So, let's assume users know what they are doing and just always return
the configured stl and stlnc values.  And if they want the statusline to
be non-distinguishable from the rest of the window space, so be it.  It
is their responsibility and Vim shall not know better what to use.

fixes: vim/vim#13366
closes: vim/vim#13488

https://github.com/vim/vim/commit/6a650bf696f1df3214b3d788947447c5bbf1a77d

Co-authored-by: Christian Brabandt <cb@256bit.org>

runtime(doc): all secure options should note this restriction in the documentation (vim/vim#13448)

Problem:  Not all secure options document their status
Solution: Describe secure context :set restrictions in each help entry

https://github.com/vim/vim/commit/8ebdbc9e6d80b707c2b2d923e702dc86bf902923

Co-authored-by: dkearns <dougkearns@gmail.com>

runtime(doc): Fix typos in several documents (vim/vim#13420)

* Fix typos in several documents
* Update runtime/doc/terminal.txt

https://github.com/vim/vim/commit/5985879e3c36383155f84649fa42d06813a1893e

Skip runtime/doc/indent.txt: not ported yet

Co-authored-by: h_east <h.east.727@gmail.com>
Co-authored-by: K.Takata <kentkt@csc.jp>