Reimplemented the fix from #2183 to fix building WASM files with Docker
on Windows again. The --workdir argument gives a path inside the Docker
container, so it must use forward slashes regardless of the default path
separator on the host OS.
This resolves https://github.com/tree-sitter/tree-sitter/issues/3454.
This brings the usage of wasmtime::Engine in line with how wasmtime
intends it to be used. All wasmtime functions that receive an Engine
always receive an `&Engine`, never an owned `Engine`. They are always
responsible for cloning the reference if they need it.
This brings the usage of wasmtime::Engine in line with how TSParser
treats TSLanguages: when setting a language to the parser, the parser is
responsible for cloning the reference to the TSLanguage. It is
counterintuitive for TSParser to have different behavior when receiving
wasmtime_engine_t.
C API users also expect this behavior, see "Memory Management"
[here](https://docs.wasmtime.dev/c-api/wasm_8h.html). Talking about the
C API: without this change, failing to clone the `wasmtime_engine_t`
(which, again, is never something API users need to do in wasmtime) and
then reusing the engine in multiple TSLanguages results in a use after
free. With this change, failing to call `wasm_engine_delete` on your
owned Engine results in a memory leak. Memory leaks are safer than
use-after-free.
The `tree-sitter-loader` crate currently always pulls
`tree-sitter-highlight` and `tree-sitter-tags` as dependencies.
However, apart from the tree-sitter CLI, most clients will not need both
of these libraries.
This commit makes the dependencies optional, but still includes them by
default in order not to break the backward compatibility.
This allows users to build parsers without having to run `test` or
`parse` to invoke the compilation process, and allows them to output the
object file to wherever they like. The `build-wasm` command was merged
into this by just specifying the `--wasm` flag.
For some reason, the linker seems to behave a bit differently with `-exported_symbols_list` on macOS vs other operating systems, so we'll disable this for now
C++ has been a headache to deal with throughout the ecosystem and for
several downstream projects. It is difficult to get working with WASM,
and induces potential issues with compilation on Windows. It has been
proven that writing scanners in C is a much better alternative, and is
the recommended way to write scanners now. C++ support will likely be
removed in 0.21.0
