This PR implements a test harness for Relocatable OCaml (ocaml/RFCs#53). The RFC defines "Relocatable" as meaning:

1. The compiler binaries are identical regardless of the installation prefix (the --prefix argument passed to configure) or the working directory in which the compiler was built (the build path).
2. The resulting compiler distribution can be used from any disk location on the system without any further alteration to the binaries.
3. The resulting compiler distribution can be used from any disk location on the system without any further alteration to the user's shell environment.

Rather than building two compilers, the first property can be checked to a sufficient degree for Relocatable OCaml by searching the installed artefacts for prefix and build path. The second and third properties can be simultaneously checked by moving the compiler from prefix to a new location, and then running a series of tests to ensure that that compiler works.

Obviously, at present OCaml cannot be configured in a way which satisfies these properties, but it is of course possible to move a compiler to a new location and change the way the compiler is invoked in order to make it work. The harness in this PR implements this approach. Everything is thus tested with a combination of known failures and shims (such as setting OCAMLLIB, or explicitly invoking bytecode binaries with ocamlrun). The three further PRs which make up the proposed changes for Relocatable OCaml are based on top of this PR, and therefore update this test harness with the revised behaviour.

There are two key differences between this test harness and the main ocamltest-based testsuite:

1. it is central to this test that it runs on the compiler having been installed to the prefix it was configured with; and
2. the test focuses more on the operation and execution of the programs than of the actual programs themselves, requiring more control over the exact commands executed to build the tests than ocamltest offers

A consequence of the "in-prefix" part is that this is not a test that should be run by default and the fact it needs to operate outside the build tree has led to an additional harness, rather than additional features in ocamltest.

The harness itself has revealed various bugs not related to Relocatable OCaml at all (cf. ocaml/flexdll#146, #13496, #13520, #13638, #13692 and #13693, in addition to a fault in the partial linker alluded to #13692 which will be fixed in a subsequent PR)

The tests performed are covered in testsuite/in_prefix/README.md.

In terms of review, the PR includes the first commit of #13728, which means all the changes in runtime/ can be ignored (as they all come from that commit). The next five commits alter the compiler:

• The compilation tests are vastly simpler if they can use Ccomp.call_linker (I mean really, really, simpler - I tried!). However, in order to that, the test harness needs to be able to control slightly more precisely the value of Config.standard_library as interpreted by Ccomp.call_linker. Having tried various approaches, the least invasive to compiler-libs seems to be to generalise Compmisc.init_path via a new Compmisc.reinit_path. There are other ways of doing this, but this one I think is the simplest that doesn't involve duplicating code from utils/ccomp.ml directly in the test harness.
• Test_ld_conf tests the handling by both ocamlrun and ocamlc of ld.conf. This test needs to be able the content of the search_path variable in Dll for which I have added a Dll.search_path function.
• Both the test harness and one of the subsequent Relocatable PRs need to iterate over the code points of a UTF-8 string, and for this reason I've added Misc.Stdlib.String.to_utf_8_seq and, as always, I'm open to suggestions for a better name.
• The test harness needs to be able to parse runtime-launch-info, so I've exposed Bytelink.read_runtime_launch_info and its associated types.
• There are various parts of the tests for reproducibility which are clang-specific. The easiest way to do this seems to be to expose the ocaml_cc_vendor variable computed in configure as Config.cc_vendor

Those opening commits clearly change the compiler, and need to be reviewed as such. The last two alter the testsuite only, and I'd beseech be reviewed from a clarity perspective only! In particular, I have 12 branches based on top of this all of which alter this test harness, so please bear in mind that while adjustments are of course possible, they come at a cost. Note also that there are a few places where behaviour is not reachable or spelled out slightly obtusely: for example, the Default_ocamlc constructor includes an ignored launch_method value, and several functions have unused parameters escaped with _. These are all altered in subsequent PRs where the reason for having this differentiation becomes (hopefully) clearer.

As far as possible, the harness learns of the configuration statically, rather than by probing the installation. In particular, this allows errors in the installation process to be detected (i.e. if the toplevel test simply tested all the .cma files it found in libdir, it would not catch the failure to have installed one of them - hence $(OTHERLIBRARIES) is passed on the command line instead. Most things are statically placed in the Config module - BINDIR and LIBDIR are passed on the command line, because Config.bindir and Config.standard_library won't have the same meaning in subsequent PRs. Especially given that the need to be able to use Ccomp.call_linker, I've not written this test to be used in a cross-compiled manner by which I mean it can test an installation which is a cross compiler, but the test harness must itself be compiled with the same (host) configuration as the compiler it's testing.

The final commit plumbs the tests into CI - it (should!) be passing both on GitHub Actions here and has also passed precheck (although I can't at present schedule a run of this precise version of the PR, as precheck seems to be down). It's also passing an even wider text matrix including Cygwin and multiple different shebang/executable/static/minimal tests in #175.

The harness code itself is structured with utility functions in module Harness and information derived about the C compiler and platform in Toolchain. Module Environment (and in particular Environment.run_process) encapsulates the configuration of the configuration of the compiler installation. Cmdline and Test_in_prefix drive the entire process with TestRelocation, TestBytecodeBinaries, TestDynlink, TestLinkModes,TestTopLevel and Test_ld_conf containing the implementations of the six tests.