The variable $(TOUCH) is initialized with the "touch" value in mkenv.mk
like for the other command line tools (rm, echo, cp, mkdir etc).  With
this, for example, Windows users can specify the path of touch.exe.

The variable $(CAT) is initialised with the "cat" value in mkenv.mk like
for the other command line tools (rm, echo, cp, mkdir etc).  With this,
for example, Windows users can specify the path of cat.exe.

How to use this feature is documented in docs/develop/cmodules.rst.

This system makes it a lot easier to include external libraries as static,
native modules in MicroPython.  Simply pass USER_C_MODULES (like
FROZEN_MPY_DIR) as a make parameter.

This change makes it so that python3 is required by default to build
MicroPython. Python 2 can be used by specifying make PYTHON=python2.

This comes about due to a recent-ish change to PEP 394 that makes the
python command more optional than before (even with Python 2 installed);
see https://github.com/python/peps/commit/cd59ec03c8ff1e75089d5872520cd0706774b35b#diff-1d22f7bd72cbc900670f058b1107d426

Since the command python is no longer required to be provided by a
distribution we need to use either python2 or python3 as commands.  And
python3 seems the obvious choice.

Rationale:

* Calling Python build tool scripts from makefiles should be done
  consistently using `python </path/to/script>`, instead of relying on the
  correct she-bang line in the script [1] and the executable bit on the
  script being set. This is more platform-independent.
* The name/path of the Python executable should always be used via the
  makefile variable `PYTHON` set in `py/mkenv.mk`. This way it can be
  easily overwritten by the user with `make PYTHON=/path/to/my/python`.
* The Python executable name should be part of the value of the makefile
  variable, which stands for the build tool command (e.g. `MAKE_FROZEN` and
  `MPY_TOOL`), not part of the command line where it is used. If a Python
  tool is substituted by another (non-python) program, no change to the
  Makefiles is necessary, except in `py/mkenv.mk`.
* This also solves #3369 and #1616.

[1] There are systems, where even the assumption that `/usr/bin/env` always
exists, doesn't hold true, for example on Android (where otherwise the unix
port compiles perfectly well).

This reverts commit 3289b9b7.
The commit broke building on MINGW because the filename became
micropython.exe.exe.  A proper solution to support more Windows build
environments requires more thought and testing.

Building mpy-cross: this patch adds .exe to the PROG name when building
executables for host (eg mpy-cross) on Windows.  make clean now removes
mpy-cross.exe under Windows.

Building MicroPython: this patch sets MPY_CROSS to mpy-cross.exe or
mpy-cross so they can coexist and use cygwin or WSL without rebuilding
mpy-cross.  The dependency in the mpy rule now uses mpy-cross.exe for
Windows and mpy-cross for Linux.

Now, to use frozen bytecode all a port needs to do is define
FROZEN_MPY_DIR to the directory containing the .py files to freeze, and
define MICROPY_MODULE_FROZEN_MPY and MICROPY_QSTR_EXTRA_POOL.

A port now just needs to define FROZEN_DIR var and add $(BUILD)/frozen.c
to SRC_C to support frozen modules.

Qstr auto-generation is now much faster so this optimisation for start-up
time is no longer needed.  And passing "-s -S" breaks some things, like
stmhal's "make deploy".

By skipping loading site.py, etc.

The whole current port gets slurped into a static lib named
"libmicropython.a". Maybe that's not ideal, but at least something
to start with.

Indeed, this flag efectively selects architecture target, and must
consistently apply to all compiles and links, including 3rd-party
libraries, unlike CFLAGS, which have MicroPython-specific setting.

?= operator does not do delayed expansion (unlike =).

  there are special tweaks and paths to be considered. Just provide some
  defaults, in case the values are undefined.
- py-version.sh does not need any bash specific features.
- Use libdl only on Linux for now. FreeBSD provides dl*() calls from libc.