Building mpy-cross automatically leads to some issues with the build
process and slows it down.  Instead, require it to be built manually.

A global definition of MP_NOINLINE was added to py/mpconfig.h long ago in
0f5bf1aa

Prints something like:

MicroPython v1.10-304-g8031b7a25 on 2019-05-02; mpy-cross emitting mpy v4

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

mpy-cross is a host, not target binary. It should not be build with the
target compiler, compiler options and other settings. For example,

If someone currently tries to build from pristine checkout the unix port
with the following command:

    make CROSS_COMPILE=arm-linux-gnueabihf-

then mpy-cross will be built with arm-linux-gnueabihf-gcc and of course
won't run on the host, leading to overall build failure.

This situation was worked around for some options in 1d8c3f4c, so add
MICROPY_FORCE_32BIT and CROSS_COMPILE to that set too.

mpy-cross doesn't depend on any code in the extmod directory so completely
exclude it from the build (extmod may still be scanned for qstrs but that
is controlled by py/py.mk).  This speeds up the build a little, and
improves abstraction of this component.

Also, make -I$(BUILD) take precedence over -I$(TOP) in case there are stray
files in the root directory that would be picked up.

Header files that are considered internal to the py core and should not
normally be included directly are:
    py/nlr.h - internal nlr configuration and declarations
    py/bc0.h - contains bytecode macro definitions
    py/runtime0.h - contains basic runtime enums

Instead, the top-level header files to include are one of:
    py/obj.h - includes runtime0.h and defines everything to use the
        mp_obj_t type
    py/runtime.h - includes mpstate.h and hence nlr.h, obj.h, runtime0.h,
        and defines everything to use the general runtime support functions

Additional, specific headers (eg py/objlist.h) can be included if needed.

Also renames "stmhal" to "stm32" in documentation and everywhere else.

$(TOP) is defined in py/mkenv.mk and should be used to refer to the top
level of this repository.

There were several different spellings of MicroPython present in comments,
when there should be only one.

make v3.81 doesn't have "undefine" so we can't use it with that version.

This is a temporary hack to allow othe Makefiles to build mpy-cross
recursively.

fmode.c should only be included for builds targetting 'pure' windows, i.e.
msvc or mingw builds but not when using msys or cygwin's gcc (see #2298).
Just checking if the OS is windows and UNAME doesn't have msys stil leaves
the gate open for builds with cygwin's gcc since UNAME there is e.g.
CYGWIN_NT-6.1-WOW.
Fix this by checking for 'mingw' explicitly in the compiler version; both
gcc and clang have the -dumpmachine flag so the check should be ok for
all platforms.

Prior to making this a config option it was previously available on these
(and all other) ports, and it makes sense to keep it enabled for mpy-cross
as well as ports that have a decent amount of space for the code.

It can still be overwritten by a port in mpconfigport.h but for almost
all cases one can use the provided default.

The -ansi flag is used for C dialect selection and it is equivalent to -std=c90.
Because it goes right before -std=gnu99 it is ignored as for conflicting flags
GCC always uses the last one.

They require mp_hal_stdout_tx_strn_cooked, which requires extra work to
add to mpy-cross.

This type was used only for the typedef of mp_obj_t, which is now defined
by the object representation.  So we can now remove this unused typedef,
to simplify the mpconfigport.h file.

When compiling with msys2's gcc there's no need to apply the binary fmode
so adjust the Makefile to reflect that.
When compiling with mingw we need to include malloc.h since there is no
alloca.h, and the 64bit detection in mpconfigport.h needs some adjustment.

This is a fix for https://github.com/micropython/micropython/issues/2209:
by default a file created using open() uses text translation mode so writing
\n to it will result in the file having \r\n. This is obviously problematic
for binary .mpy files, so provide functions for setting the open mode
and use binary mode in mpy-cross' main().

.mpy files contain the name of the source file that they were compiled
from.  This patch adds a way to change this name to an arbitrary string,
specified on the command line with the -s option.  The default is to use
the full name of the input filename.

This new -s option is useful to strip off a leading directory name so
that mpy-tool.py can freeze packages.

Building in 32-bit mode was only to reduce binary size on 64-bit machines
and is otherwise not needed.  Having it forced to 32-bit meant an
unnecessary dependency on 32-bit libraries that is now removed.

This component allows to generate .mpy files (pre compiled bytecode)
which can be executed within any MicroPython runtime/VM.