fix #3436

Includes:
vim-patch:8.0.1038: strike-through text not supported

Before this, --embed UIs (without --headless) would not trigger UIEnter.

For TUI, maybe UIEnter isn't useful, but:
- It is less "surprising"/special.
- Makes documentation simpler.
- When TUI becomes a coprocess, it will happen anyway.

Even though it's always zero currently, it's less confusing if all UIs
have the same fields.

simplify handling of default colors

nvim is always true color internally, remove ui_rgb_attached() check.

Fix "runtime termguicolors" test. The test actually reflected broken behavior
in (parent) nvim: nvim_ui_set_option("rgb", true) was not respected by existing
:terminal instances, so all 16-palette colors became dark blue.

Forcing insert-mode after the first paste-chunk seems to work, as an
alternative to a9e2bae0eb69 (insert-before-cursor).

NB: Dot-repeat needs to match the original action.  Since a9e2bae0eb69
changed paste to insert-before-cursor, dot-repeat must also. But that
makes dot-repeat unpleasant/unusual.

Inserting "after" the cursor in Normal-mode, for big paste-streams, is
not reliable: sometimes the text "after" the cursor ends up in the
middle of the pasted text.  Maybe the cursor position is not updated?

To avoid weird behavior, always paste "before".  Maybe nvim_put() or
vim.paste() can be fixed more properly later.

Problem:  If multiple paste "chunks" are streamed, chunks after the
          first line are pasted into the buffer.
Solution: Check for cmdline-mode for all chunks in a paste-stream.

- Workaround #10966: 'paste' option is not always reset.
- In any case there's not much reason to wait until phase=3, because
  pasting in cmdline-mode skips lines after the first line (thus the
  `:set paste .. :set nopaste` dance happens only ~once).