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.

The latexpdf target needs images that fit on the page, and does not support
gifs.

Fixes issue #3844.

Object representation D only works with no floats, or double precision
floats.

With this and previous patches the stm32 port can now be compiled using
object representation D (nan boxing).  Note that native code and frozen mpy
files with float constants are currently not supported with this object
representation.

Because this function is simple it saves code size to have it inlined.
Being an auxiliary helper function (and only used in the py/ core) the
argument should always be an mp_obj_module_t*, so there's no need for the
assert (and having it would require including assert.h in obj.h).

It's a very simple function and saves code, and improves efficiency, by
being inline.  Note that this is an auxiliary helper function and so
doesn't need mp_check_self -- that's used for functions that can be
accessed directly from Python code (eg from a method table).

mp_obj_module_get_globals() returns a mp_obj_dict_t*, and type->locals_dict
is a mp_obj_dict_t*, so access the map entry of the dict directly instead
of needing to cast this mp_obj_dict_t* up to an object and then calling the
mp_obj_dict_get_map() helper function.

Printing debugging info by defining MICROPY_DEBUG_VERBOSE expects
a definition of the DEBUG_printf function which is readily available
in printf.c so include that file in the build. Before this patch
one would have to manually provide such definition which is tedious.

For the msvc port disable MICROPY_USE_INTERNAL_PRINTF though: the
linker provides no (easy) way to replace printf with the custom
version as defined in printf.c.

The definition of DEBUG_printf doesn't depend on
MICROPY_USE_INTERNAL_PRINTF so move it out of that preprocessor
block and compile it conditionally just depending on the
MICROPY_DEBUG_PRINTERS macro. This allows a port to use DEBUG_printf
while providing it's own printf definition.

It seems that some cards do not tolerate releasing the card (by setting CS
high) after issuing CMD17 (and 18) and raising it again before reading
data. Somehow this causes the 0xfe data start marker not being read and
SDCard.readinto() is spinning forever (or until this byte is in the data).

This seems to fix weird behviour of SDCard.readblocks() returning different
data, also solved hanging os.mount() for my case with a 16GB Infineon card.

This stackexchange answer gives more context:
https://electronics.stackexchange.com/questions/307214/sd-card-spi-interface-issue-read-operation-returns-0x3f-0xff-instead-of-0x7f-0#307268

Prior to this patch there was a large latency for executing scheduled
callbacks when when Python code is sleeping: at the heart of the
implementation of sleep_ms() is a call to vTaskDelay(1), which always
sleeps for one 100Hz tick, before performing another call to
MICROPY_EVENT_POLL_HOOK.

This patch fixes this issue by using FreeRTOS Task Notifications to signal
the main thread that a new callback is pending.

This patch allows scripts to have more control over the software WDT.  If
an instance of machine.WDT is created then the underlying OS is prevented
from feeding the software WDT, and it is up to the user script to feed it
instead via WDT.feed().  The timeout for this WDT is currently fixed and
will be between 1.6 and 3.2 seconds.

A flash erase/write takes a while and during that time tasks may be
scheduled via an IRQ.  To prevent overflow of the task queue (and loss of
tasks) call ets_loop_iter() before and after slow flash operations.

Note: if a task is posted to a full queue while a flash operation is in
progress then this leads to a fault when trying to print out the error
message that the queue is full.  This patch doesn't try to fix this
particular issue, it just prevents it from happening in the first place.

Fixes issue #3865.

Fixes issue #3914.

For generating functions there is no need to wrap the bytecode function in
a generator wrapper instance.  Instead the type of the bytecode function
can be changed to mp_type_gen_wrap.  This reduces code size and saves a
block of GC heap RAM for each generator.

This feature is controlled at compile time by MICROPY_PY_URE_SUB, disabled
by default.

Thanks to @dmazzella for the original patch for this feature; see #3770.

This feature is controlled at compile time by
MICROPY_PY_URE_MATCH_SPAN_START_END, disabled by default.

Thanks to @dmazzella for the original patch for this feature; see #3770.

This feature is controlled at compile time by MICROPY_PY_URE_MATCH_GROUPS,
disabled by default.

Thanks to @dmazzella for the original patch for this feature; see #3770.

This function may be called from a UART IRQ, which may interrupt the system
when it is erasing/reading/writing flash.  In such a case all code
executing from the IRQ must be in iRAM (because the SPI flash is busy), so
put mp_keyboard_interrupt in iRAM so ctrl-C can be caught during flash
access.

This patch also takes get_fattime out of iRAM and puts it in iROM to make
space for mp_keyboard_interrupt.  There's no real need to have get_fattime
in iRAM because it calls other functions in iROM.

Fixes issue #3897.

Before this patch the context manager's __aexit__() method would not be
executed if a return/break/continue statement was used to exit an async
with block.  async with now has the same semantics as normal with.

The fix here applies purely to the compiler, and does not modify the
runtime at all. It might (eventually) be better to define new bytecode(s)
to handle async with (and maybe other async constructs) in a cleaner, more
efficient way.

One minor drawback with addressing this issue purely in the compiler is
that it wasn't possible to get 100% CPython semantics.  The thing that is
different here to CPython is that the __aexit__ method is not looked up in
the context manager until it is needed, which is after the body of the
async with statement has executed.  So if a context manager doesn't have
__aexit__ then CPython raises an exception before the async with is
executed, whereas uPy will raise it after it is executed.  Note that
__aenter__ is looked up at the beginning in uPy because it needs to be
called straightaway, so if the context manager isn't a context manager then
it'll still raise an exception at the same location as CPython.  The only
difference is if the context manager has the __aenter__ method but not the
__aexit__ method, then in that case uPy has different behaviour.  But this
is a very minor, and acceptable, difference.

It remains disabled for the 512k build.

And some ports (eg esp8266) don't have it.