When building a cross-compiler, the runtime will run on the target, not
the host so:
- set `cross_compiling` by comparing `build` to `target` (rather than to
  `host`), as this variable will be used later
- use `target` to set up the tool prefix,
- as the libtool configuration will configure a `build` to `host`
  toolchain, temporarily assign `host*` values to `target*` values

Instead of using `strip` unconditionally to build `tmpheader.exe`, use
the `strip` command detected by `libtool` during configure so that it is
replaced with `:` when the command is absent and it becomes easy to
override it if need be

GNU strip can be called safely on binaries generated by cl as well as by
MinGW GCC (even if it doesn't produce a smaller executable for
cl-generated binaries) so invoke strip also on Windows so that MinGW
binaries are properly stripped
Tested with GNU strip 2.42

Allow the use of *-*-ocaml or *-*-*-ocaml target triplets to stand for
freestanding cross-compilers by temporarily rewriting the target OS to
`none` when generating the canonical target

This allows to use *-*-ocaml and *-*-*-ocaml prefixes for cross-compiler
specific toolchains, so that all the specific tools (for instance
aarch64-solo5-ocaml-gcc, etc.) are automatically discovered

Make sure that we don't detect zstd on build when we are building a
cross-compiler, as the native zstd has no reason to be compatible with
the cross toolchain

Define cross.opt and cross-install targets

FIXME: Problems of inconsistencies between compilation options (only
about zstd?) between the native toolchain and the cross toolchain may
break the build?

Solo5 is single-core with no scheduler, so avoid the useless memory
waste

Note that since PR#13272 the maximum number of domains can set using a
parameter in OCAMLRUNPARAM so `getenv` might be a better place to set
this limit in the future