Problem:
Some tests fail with $SHELL=fish #6172
Related: https://github.com/neovim/neovim/pull/6176

Solution:
Replace "echo -n" with "printf", because "echo" in sh may be provided
as a shell builtin, which does not accept an "-n" flag to avoid a
trailing newline (e.g. on macos). "printf" is more portable (defined by
POSIX) and it does not output a trailing newline by itself.
Fixes #6172

TODO:
Other test failures may be related to "session leader" issue: https://github.com/neovim/neovim/issues/2354
Checked by running `:terminal ./build/bin/tty-test` from Nvim with
`shell=/bin/fish` (inherited from `$SHELL`) and it indeed complains
about "process does not own the terminal". With `shell=sh` it doesn't complain. And
unsetting `$SHELL` seems to make `nvim` to fall back to `shell=sh`.

    FAILED   test/functional/terminal/tui_spec.lua @ 1017: TUI paste: terminal mode
    test/functional/terminal/tui_spec.lua:1024: Row 1 did not match.
    Expected:
      |*tty ready                                         |
      |*{1: }                                                 |
      |*                                                  |
      |                                                  |
      |{5:^^^^^^^                                           }|
      |{3:-- TERMINAL --}                                    |
      |{3:-- TERMINAL --}                                    |
    Actual:
      |*process does not own the terminal                 |
      |*                                                  |
      |*[Process exited 2]{1: }                               |
      |                                                  |
      |{5:^^^^^^^                                           }|
      |{3:-- TERMINAL --}                                    |
      |{3:-- TERMINAL --}                                    |

    To print the expect() call that would assert the current screen state, use
    screen:snapshot_util(). In case of non-deterministic failures, use
    screen:redraw_debug() to show all intermediate screen states.

    stack traceback:
        test/functional/ui/screen.lua:622: in function '_wait'
        test/functional/ui/screen.lua:352: in function 'expect'
        test/functional/terminal/tui_spec.lua:1024: in function <test/functional/terminal/tui_spec.lua:1017>

    FAILED   test/functional/terminal/tui_spec.lua @ 1551: TUI forwards :term palette colors with termguicolors
    test/functional/terminal/tui_spec.lua:1567: Row 1 did not match.
    Expected:
      |*{1:t}ty ready                                         |
      |                                                  |
      |*                                                  |
      |                                                  |
      |{2:^^^^^^^                                           }|
      |                                                  |
      |{3:-- TERMINAL --}                                    |
    Actual:
      |*{1:p}rocess does not own the terminal                 |
      |                                                  |
      |*[Process exited 2]                                |
      |                                                  |
      |{2:^^^^^^^                                           }|
      |                                                  |
      |{3:-- TERMINAL --}                                    |

    To print the expect() call that would assert the current screen state, use
    screen:snapshot_util(). In case of non-deterministic failures, use
    screen:redraw_debug() to show all intermediate screen states.

    stack traceback:
        test/functional/ui/screen.lua:622: in function '_wait'
        test/functional/ui/screen.lua:352: in function 'expect'
        test/functional/terminal/tui_spec.lua:1567: in function <test/functional/terminal/tui_spec.lua:1551>

Co-authored-by: zeertzjq <zeertzjq@outlook.com>
Co-authored-by: famiu <famiuhaque@protonmail.com>

Problem:
On Windows, :make does not display the output of the program it runs.
The cause is the default 'shellpipe'.  On Linux, nvim uses `tee` to redirect the
output to both stdout and the error file.  In Windows, for both cmd.exe and
powershell, the output is only redirected to the error file.

Solution:
- On Windows, change the 'shellpipe' default to "2>&1| tee".
    - Nvim includes `tee` in its Windows package.
- Document recommended defaults for powershell.

Fixes #12910

Problem:
The calculation of `len` in `make_filter_cmd` for powershell falls short
by one character for the following ex command:
  :%w !sort
This command satisfies these conditions:
  - `itmp` is not null
  - `otmp` is null
__NOTE__ that other shells circumvent this bug only because of `len`
allocation for six extra characters: a pair of curly braces and four
spaces:
  https://github.com/neovim/neovim/blob/cfdb4cbada8c65aa57e69776bcc0f7b8b298317a/src/nvim/ex_cmds.c#L1551-L1554
If allocation for these six characters are removed, then bash also faces
the same bug.

Solution:
Add allocation for 6 extra bytes. 1 would do, but let's keep powershell
in sync with other shells as much as possible.

Extend the capabilities of is_os to detect more platforms such as
freebsd and openbsd. Also remove `iswin()` helper function as it can be
replaced by `is_os("win")`.

Problem:
If the shell command passed to the filtered bang command isn't found,
the error isn't redirected to the temp.out file when shell is set to
powershell.

Solution: Use anonymous function with Invoke-Command operator (&).

Problem:
`Start-Process` requires the command to be split into the shell
command and its arguments. Previously it was done by parsing, which
didn't handle cases such as
  - commands with escaped space in their filepath
  - quoted commands with space in their filepath

Solution:
Use
  - `pwsh -Command` instead of `Start-Process`
  - `Get-Content` instead of `-RedirectStandardInput`
  - `Out-File` instead of `-RedirectStandardOutput`

Problem:
Since 0b9664f5240be4d9e9d6882fcd398970fd3a9532 powershell filtered
:[range]! commands with args causes error:
"Start-Process: A positional parameter cannot be found that accepts argument ..."

Solution:
Pass args to Start-Process via `-ArgumentList`.
closes #19250