Relying on $(OS) doesn't work as it's too naive, so we check if $PATH
contains a colon instead.

Closes https://github.com/neovim/neovim/issues/31027

This automatically downloads and uses the correct luals binary for the
currently used system. `make luals` will run luals on all lua files in
`runtime`.

We download lua-language-server manually instead of relying on
contributors downloading it on their own (like with stylua) as
lua-language-server is updated frequently which may cause unnecessary
friction. Therefore, we download a pinned version of luals which we then
can manually bump when needed. This can be re-evaluated if luals becomes
more stable in the future.

Currently this is not run when using `make lint` since cmake style "file
caching" doesn't seem possible at the moment. This is because checking a
single file doesn't seem to work.

Work on https://github.com/neovim/neovim/issues/24563.

Co-authored-by: Axel <axelhjq@gmail.com>
Co-authored-by: Colin Kennedy <colinvfx@gmail.com>
Co-authored-by: Daiki Noda <sys9kdr@users.noreply.github.com>
Co-authored-by: Evgeni Chasnovski <evgeni.chasnovski@gmail.com>
Co-authored-by: Jean-Jacq du Plessis <1030058+jj-du-plessis@users.noreply.github.com>
Co-authored-by: Juan Giordana <juangiordana@gmail.com>
Co-authored-by: Lincoln Wallace <locnnil0@gmail.com>
Co-authored-by: Matti Hellström <hellstrom@scm.com>
Co-authored-by: Steven Locorotondo <steven.locorotondo@justeattakeaway.com>
Co-authored-by: Yochem van Rosmalen <git@yochem.nl>
Co-authored-by: glepnir <glephunter@gmail.com>
Co-authored-by: ifish <fishioon@live.com>

There appears to be a bug in `make` where if a rule asks `make` to
invoke a command called `foo`, and `foo` exists somewhere in `$PATH` as
a directory (not an executable file), `make` will attempt to `execve`
that directory instead of continuing to search in later parts of the
`$PATH` for `foo` as a true executable.

The cause can be traced back to a bug in Make 4.3 which stems from their
use of the findprog function in Gnulib. This was reported to the Make
maintainers here:

https://savannah.gnu.org/bugs/index.php?57962

and then forwarded to the Gnulib maintainers here:

https://github.com/coreutils/gnulib/commit/7b1de4a

Make 4.4 does not have this bug, and I can confirm that I'm able to run
make in the Neovim repo with no further modifications to my system than
upgrading the version of make I'm using to 4.4 or 4.4.1.

As the change is small enough, and it's unlikely that make version
around the world is going to be updated in a timely manner, it makes
sense to just add a workaround for this. Using `command -v` to resolve
the `cmake` command, similar to what is already being done with
`cmake3`, makes it work correctly in all cases. Continuing to include
`... || echo cmake` at the end means that if neither `cmake3` nor
`cmake` are installed, the user will still see a message about CMake
being missing.

Co-authored-by: Jake Zimmerman <zimmerman.jake@gmail.com>

This will fix the following error when using generators that have a
space in them, e.g. "Unix Makefiles":

"CMake Error: Could not create named generator Unix".

Closes https://github.com/neovim/neovim/issues/30218.

Using powershell as the default windows shell as using cmd alters $PATH
in a way that makes building neovim fail (powershell prioritizes visual
studio tools which is arguably more correct).

This was tested with gnu make for windows, which can be installed with
e.g. scoop. It does not work with nmake and it is extremely unlikely we
want to add nmake support as the makefile is merely supposed to be
syntactic sugar for the most common case. For similar reasons, the only
supported generator is ninja.

This reverts commit 7f6ff829aa2347eb940d8e70a825ea335d8f15ed.

The given reasoning and usecase is unsatisfactory. While it is true that
it allows to run `make build/bin/nvim`, it can easily be recreated with
`ninja -C build bin/nvim` which does the exact same thing. This minor
convenience is not worth adding the extra code given how rare this
usecase should be.

Debugging dependencies is rare so a Debug build type is usually not
needed. In cases where it _is_ needed it is easy to rebuild in Debug
mode. But since Release builds are more common, it makes more sense as a
default.

For Neovim itself we stick with a Debug build as a default, since
rebuilding and debugging is done _much_ more frequently than with
dependencies (which we _mostly_ expect to "just work").

Also remove the CMAKE_BUILD_TYPE variable in the Makefile, since this is
set by default in CMake.

Summary: Separate the lint job (`make lintdoc`) to validate runtime/doc,
it is no longer as a part of functionaltest (help_spec).

Build (cmake) and CI:

- `make lintdoc`: validate vimdoc files and test-generate HTML docs.
  CI will run this as a part of the "docs" workflow.

- `scripts/lintdoc.lua` is added as an entry point (executable script)
  for validating vimdoc files.

scripts/gen_help_html.lua:

- Move the tests for validating docs and generating HTMLs from
  `help_spec.lua` to `gen_help_html`. Added:
  - `gen_help_html.run_validate()`.
  - `gen_help_html.test_gen()`.

- Do not hard-code `help_dir` to `build/runtime/doc`, but resolve from
  `$VIMRUNTIME`. Therefore, the `make lintdoc` job will check doc files
  on `./runtime/doc`, not on `./build/runtime/doc`.

- Add type annotations for gen_help_html.

- remove "ran-" prefix from touch files as it's redundant since the
  they're already in the directory named `touches`.
- Include `contrib` when formatting with `make formatlua`.
- Use TARGET_FILE generator expression instead of assuming the
  executable location.
- reuse logic that determines whether to use lua or luajit.
- add translations to the `nvim` target.

Makefile improvements:
- rename variable `CMAKE_PRG` to `CMAKE` to make it more consistent with
  the builtin `MAKE` variable.
- stop propagating flags to generator. Users should use cmake for
  non-standard use cases.
- remove `+` prefix from targets. If the user for whatever reason wants
  to dry-run a target then they should be able to.