Order out-of-bounds check, completion check, and increment in the right way.

There's single str_index_to_ptr() function, called for both bytes and
unicode objects, so should handle each properly.

We have adopted POSIX-compatible error numbers as MicroPython's native.

Also, fix a warning text (remove "duplicate" BytesWarning).

Something like:

if foo == "bar":

will be always false if foo is b"bar". In CPython, warning is issued if
interpreter is started as "python3 -b". In MicroPython,
MICROPY_PY_STR_BYTES_CMP_WARN setting controls it.

Currently, MicroPython runs GC when it could not allocate a block of memory,
which happens when heap is exhausted. However, that policy can't work well
with "inifinity" heaps, e.g. backed by a virtual memory - there will be a
lot of swap thrashing long before VM will be exhausted. Instead, in such
cases "allocation threshold" policy is used: a GC is run after some number of
allocations have been made. Details vary, for example, number or total amount
of allocations can be used, threshold may be self-adjusting based on GC
outcome, etc.

This change implements a simple variant of such policy for MicroPython. Amount
of allocated memory so far is used for threshold, to make it useful to typical
finite-size, and small, heaps as used with MicroPython ports. And such GC policy
is indeed useful for such types of heaps too, as it allows to better control
fragmentation. For example, if a threshold is set to half size of heap, then
for an application which usually makes big number of small allocations, that
will (try to) keep half of heap memory in a nice defragmented state for an
occasional large allocation.

For an application which doesn't exhibit such behavior, there won't be any
visible effects, except for GC running more frequently, which however may
affect performance. To address this, the GC threshold is configurable, and
by default is off so far. It's configured with gc.threshold(amount_in_bytes)
call (can be queries without an argument).

Allows to build the library variant for other archs in parallel.

3-arg form:

stream.write(data, offset, length)

2-arg form:

stream.write(data, length)

These allow efficient buffer writing without incurring extra memory
allocation for slicing or creating memoryview() object, what is
important for low-memory ports.

All arguments must be positional. It might be not so bad idea to standardize
on 3-arg form, but 2-arg case would need check and raising an exception
anyway then, so instead it was just made to work.

Make variable MICROPY_SSL_AXTLS=1 should be defined to activate modussl_axtls
and link with -laxtls.

LTO can't "see" inside naked functions, but we can mark `nlr_push_tail` as used.

This follows source code/header file organization similar to few other
objects, and intended to be used only is special cases, where efficiency/
simplicity matters.

Allocating it for each read/write operation is a memory fragmentation
hazard.

However, as it requires linking with external libraries, it actually
should be ste on Makefile level.

Namespace packages are natural part of Python3, CPython3 doesn't have such
warning, it made sense only from point of view of Python2 legacy.

Just as maximum allocated block size, it's reported in allocation units
(not bytes).

Previously, if there was chain of allocated blocks ending with the last
block of heap, it wasn't included in number of 1/2-block or max block
size stats.

It's now accessed via the MP_STATE_THREAD macro.

Now only the bits that really need to be written in assembler are written
in it, otherwise C is used.  This means that the assembler code no longer
needs to know about the global state structure which makes it much easier
to maintain.

We rely on the port setting and adjusting the stack size so there is
enough room to recover from hitting the stack limit.

The GIL macros are needed even if threading is not enabled.

There is no need since the GIL already makes gc and qstr operations
atomic.

This makes the VM/runtime thread safe, at the cost of not being able to
run code in parallel.

GC_EXIT() can cause a pending thread (waiting on the mutex) to be
scheduled right away.  This other thread may trigger a garbage
collection.  If the pointer to the newly-allocated block (allocated by
the original thread) is not computed before the switch (so it's just left
as a block number) then the block will be wrongly reclaimed.

This patch makes sure the pointer is computed before allowing any thread
switch to occur.

So the underlying thread implementation can do any necessary bookkeeping.

By using a single, global mutex, all memory-related functions (alloc,
free, realloc, collect, etc) are made thread safe.  This means that only
one thread can be in such a function at any one time.