Copy python directory to python3. (#1204)

Porting Python2 to Python3 is hard enough. I don't know if we can maintain single source across both.
This is not a great situation.

Update version do d5.11.8 051108 2022-01-14.

new installer and bugfixes

This release introduces a new installer that supports a simple, source-based
distribution containing a bootstrap compiler in C++.  Because it is
source-based, we only need to provide a small number of distributions (4) to
cover all tested systems.  And because it includes a bootstrap, we no longer
have to provide separate binary and source releases for each platform.

cm3 is now regularly built and tested an ARM.  See
https://app.circleci.com/pipelines/github/modula3/cm3

This release also includes a fix for alignment of 64-bit data on 32-bit
systems, so the I368_NT and I386_LINUX platforms now work.

It also includes a number of fixes for formal default and field default array
constructors, bringing cm3 more in-line with the language definition.

Finally, there have been a number of fixes to the compiler test suite.

bugfix release to reenable bootstrapping

scripts: Consider Cygwin, Mingw to be C backend only. (#698)

Though strictly speaking I386_CYGWIN and I386_MINGW
have worked with the m3cc backend, and this change
does not change that.

Do not copy .o/.obj/.mo/.io into C backend bootstraps.

Change some starts with to contains (riscv, solaris).

Mac/arm64: Homebrew for ODBC, X11, OpenGL. (#653)

Co-authored-by: jay <[email protected]>

Coroutine: Fix non-Linux/amd64 when combining m3c and C. (#641)

void* vs. Context*

Coroutine: Fix non-Linux/amd64 when combining m3c and C. (#641)

void* vs. Context*

NT bootstrap: Empty LibcCompatC.c.

This file attempts to solve a problem, but it only works
sometimes, and breaks things sometimes.

The problem is taking an existing static m3core.lib/libm3.lib
that contains references to C runtime, generated by compiler
or manual calls to things in .h files, and link that with a newer
compiler/runtime.

The C runtime ABI is unfortunately not generally compatible.
Certainly not going backwards, there are new calls required,
and perhaps not going forward.

This actually broke me yesterday.
An available working "easier" solution is to use boot1.py
and defer any C compilation until you have arrived at your
actual C toolchain. Do not try to mix objects between toolsets.
This is an unfortunate compromise.
In time we might might be able to limit ourselves to a more portable
subset, but that is not super likely, due to things as simple-seeming
but complicated as integer/float conversion.

More likely we should delete this file entirely, rather than
leave it almost empty.

RISCV64_LINUX support.