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

Since "read-exactly" stream refactor, where stream.read(N) will read
exactly N bytes (unless EOF), http_server* examples can't any longer do
client_socket.read(4096) and expect to get full request (it will block
on HTTP/1.1 client). Instead, read request line by line, as the HTTP
protocol requires.

They will fail because the GIL is disabled on the unix build.

Threading support is still very new so stay conservative at this point
and enable threading without the GIL.  This requires users to protect
concurrent access of mutatable Python objects (eg lists) with locks at
the Python level (something you should probably do anyway).  The
advantage is that there is less of a performance hit for non-threaded
code, because the VM does not need to constantly release/acquire the GIL.

In the future the GIL will be made more efficient.  There is also room to
improve the efficiency of non-GIL code by not using mutex's if there is
only one thread active.

Due to the way modern compilers work (allocating space for stack vars once
at tha start of function, and deallocating once on exit from), using
intermediate stack buffer of big size caused blockage of 4K (PATH_MAX)
on stack for the entire duration of MicroPython execution.

E.g. -X heapsize=16Kfoo, -X heapsize=1G will lead to error.

Instead of allocating new array object header again and again, causing
memory fragmentation.

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.

It's memory fragmentation hazard to allocate 1-char string each time by
calling read() method.

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

By adjusting parser allocation policy.

Leads to less fragmentation at teh time user code starts.

But disable it for coverage build, as its extra warninsg aren't compatible
with K&R C BerkeleyDB uses.

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.