Problem: We use the `p_force_on` and `p_force_off` variables to check if a variable is immutable and what its default value is. This is not only hacky and unintuitive, but also is limited to only boolean options.

Solution: Replace `p_force_on` and `p_force_off` with an `immutable` property for options, which indicates if an option is immutable. Immutable options cannot be changed from their default value.

Ref: #25672.

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.

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:
'nofsync' may lose data if the system has a hard shutdown. #9888

Solution:
Change default to 'fsync'. This may be revisited in the future when
'nofsync' can be made safer.

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>

Problem:  EXPAND flag set for filetype option
Solution: Remove P_EXPAND flag from the 'filetype' option

Remove P_EXPAND flag from the 'filetype' option

Problem:  P_EXPAND flag is erroneously set for 'filetype' option
Solution: Remove the P_EXPAND flag

This flag is used by string options that accept file path values.  See
:help set_env.

This appears to have been included in d5e8c92 and resulted from an
incorrect implementation of 'filetype' completion.

See vim/vim#12900 for a small discussion.

related: vim/vim#12900
closes: vim/vim#13416

https://github.com/vim/vim/commit/3932072ab435eb171ab55b2a2c0185358cd0d7bf

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