This improves efficiency of GIL release within the VM, by only doing the
release after a fixed number of jump-opcodes have executed in the current
thread.

It's more efficient using the system mutexs instead of synthetic ones with
a busy-wait loop.  The system can do proper scheduling and blocking of the
threads waiting on the mutex.

Depending on the thread scheduler, a busy-wait loop can hog the CPU and
make the tests very slow.  So convert such loops to loops that have an
explicit sleep, allowing the worker threads to do their job.

For small ports which don't have all features enabled.

This was a debug output for initial porting, breaks tests.

To make skippable.

This allows using the test runner for other scenarios than just
testing uPy itself.
The principle of comparing either to CPython or else to a .exp
file is really handy but to be able to test custom modules not
built into micropython.exe one needs to be able to specify the
module search path a.k.a MICROPYPATH.

Should work for QEMU networking with soon-to-merged upstream patch.

MicroPython guarantees '/' to be a path separator, so extra constant taking
precious ROM space are not needed. MicroPython never had such constant, only
one vendor port had it (now unmaintained).

Just one sample is updated with  on()/off() for now, there should be
remaining sample(s) showing .value() use (but more can be converted later,
as long as 1 or so good samples of .value() remains).

WiPy is the only port with ADC and SD, so they shouldn't be included in
other ports' documentation.

os.stat('/') now works and returns a mostly-empty tuple.  Really all that
is useful is the mode which tells that it's a directory.

On the PYBv1.0, X1 maps to A0, not B6.

The pin had to be changed to get the I2C sensors on board to work.

ipoll() allows to poll streams without allocating any memory: this method
returns an iterator (a poll object itself), and the iterator yields
preallocated "callee-owned tuple" with polling results for each active
stream. The only operation a caller is allowed to do with this tuple is
extracting values from it (storing the tuple as a whole somewhere is
not allowed).

Previous to this patch, for large chunks of bytecode that originated from
a single source-code line, the bytecode-line mapping would generate
something like (for 42 bytecode bytes and 1 line):

  BC_SKIP=31  LINE_SKIP=1
  BC_SKIP=11  LINE_SKIP=0

This would mean that any errors in the last 11 bytecode bytes would be
reported on the following line.  This patch fixes it to generate instead:

  BC_SKIP=31  LINE_SKIP=0
  BC_SKIP=11  LINE_SKIP=1

This patch implements support for class methods __delattr__ and __setattr__
for customising attribute access.  It is controlled by the config option
MICROPY_PY_DELATTR_SETATTR and is disabled by default.

If the mounted object doesn't have a "mount" method then assume it's a
block device and try to detect the filesystem.  Since we currently only
support FAT filesystems, the behaviour is to just try and create a VfsFat
object automatically, using the given block device.

Each method asserts and deasserts signal respectively. They are equivalent
to .value(1) and .value(0) but conceptually simpler (and may help to avoid
confusion with inverted signals, where "asserted" state means logical 0
output).

The aapcs-linux ABI is not required, instead the default aapcs ABI is
enough.  And using the default ABI means that the provided libgcc will now
link with the firmware without warnings about variable vs fixed enums.

Although the binary size increases by about 1k, RAM usage is slightly
decreased.  And libgcc may prove useful in the future for things like
long-long division.

It seems that the gcc toolchain on the RaspberryPi
likes %progbits instead of @progbits. I verified that
%progbits also works under x86, so this should
fix #2848 and fix #2842

I verified that unix and mpy-cross both compile
on my RaspberryPi and on my x64 machine.

The internal map/set functions now use size_t exclusively for computing
addresses.  size_t is enough to reach all of available memory when
computing addresses so is the right type to use.  In particular, for
nanbox builds it saves quite a bit of code size and RAM compared to the
original use of mp_uint_t (which is 64-bits on nanbox builds).

For archs that have 16-bit pointers, the asmxtensa.h file can give compiler
warnings about left-shift being greater than the width of the type (due to
the inline functions in this header file).  Explicitly casting the
constants to uint32_t stops these warnings.

In other words, where first path component is an empty string.