The extension was unintentionally overwritten in cherry-pick commit
46c7122

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

Recall that the only currently officially supported configurations are
when `build` ~ `host` = `target`, where '~' means that the code
generated for `host` runs on `build` even when they differ (such as when
`build` is `x86_64-pc-cygwin` and `host` is `x86_64-pc-windows` (MSVC)
or `x86_64-w64-mingw32`).

Even though this is not officially supported yet, many projects (such as
Mirage and the opam-cross-* repositories) use OCaml cross compilers. All
those projects generate a cross compiler by assuming a non-cross OCaml
compiler is available in `PATH` (where non-cross means generating code
that will run on `host`). For that they need a C compiler and binutils
for `target` in order to build the runtime. (Note that the non-cross
compiler will link its own (`build`/`host`) runtime into the generated
`.opt` cross compilers rather than the just-compiled target runtime.)

Indeed, in that setup the runtime will run (only) on the `target` 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.

Note that all these changes are transparent when `host` = `target`.

As the C toolchain used being configured is generating code for
`target`, use `target` in every test that is done according to the
toolchain.

Note that all these changes are transparent when `host` = `target`.

Import `ax_prog_cc_for_build` from the Autoconf Macro Archive to detect
the C toolchain for the build machine when (and only when) we are
generating a cross compiler, namely when code generated for the target
doesn't run on the build machine
Use this build C toolchain by default to compile and link `sak`
Link `sak` by calling directly `SAK_CC` instead of `MKEXE_VIA_CC` to use
by default the same compiler to link than to compile `sak`, instead of
always requiring both to be overridden; this assumes that the full set
of flags that end up in `MKEXE_VIA_CC` are not really necessary to link
`sak` since it is a really simple program

When building a cross compiler using an already built non-cross
compiler, check that they are of the same version as a sanity check, as
the cross compiler will be linked using the OCaml code in the source
tree and the C runtime from the non-cross compiler

…ives

Define cross.opt and cross-install targets

WIP:
1. is there a better way to find the flags to link the cross-compilers
   with `zstd` when they should be?
2. cross-install target should be tested again, it should probably use
   installopt instead of install
3. revise the RUNTIME_BUILD_OVERRIDES, move them to a different commit
   if still required

Accept `*-none` and `*-elf*` triplets for all the architectures with a
native backend to describe the corresponding freestanding target

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.) can be discovered automatically by
`configure`