- This then provides support for floats in the struct package

Eg, "() + 1" now tells you that __add__ is not supported for tuple and
int types (before it just said the generic "binary operator").  We reuse
the table of names for slot lookup because it would be a waste of code
space to store the pretty name for each operator.

Defining NDEBUG (to any value, even 0) disables debugging.  Otherwise,
if it's not defined, debugging is enabled.

This makes the code (more) compatible with the C99 standard.

- namedtuple was wrongly using MP_OBJ_QSTR_VALUE instead of mp_obj_str_get_qstr,
so when passed a non-interned string it would segfault; fix this by using mp_obj_str_get_qstr
- store the namedtuple field names as qstrs so it is not needed to use mp_obj_str_get_qstr
everytime the field name has to be accessed. This also slighty increases performance when
fetching attributes

After vstr refactor. Fixes #1084.

There was really weird warning (promoted to error) when building Windows
port. Exact cause is still unknown, but it uncovered another issue:
8-bit and unicode str_make_new implementations should be mutually exclusive,
and not built at the same time. What we had is that bytes_decode() pulled
8-bit str_make_new() even for unicode build.

To somewhat unbreak -DSTATIC="" compile.

See issue #699.

It needs to be scanned by GC.  Thanks to Daniel Campora.

With this patch str/bytes construction is streamlined.  Always use a
vstr to build a str/bytes object.  If the size is known beforehand then
use vstr_init_len to allocate only required memory.  Otherwise use
vstr_init and the vstr will grow as needed.  Then use
mp_obj_new_str_from_vstr to create a str/bytes object using the vstr
memory.

Saves code ROM: 68 bytes on stmhal, 108 bytes on bare-arm, and 336 bytes
on unix x64.

This patch allows to reuse vstr memory when creating str/bytes object.
This improves memory usage.

Also saves code ROM: 128 bytes on stmhal, 92 bytes on bare-arm, and 88
bytes on unix x64.

This allows an exception to propagate correctly through a finally
handler.

Addresses issue #1073.

Addresses issue #1067.

Reduces stmhal code size by about 250 bytes.

See issue #699.

See issue #699.

Only modules (not packages) supported now. Source modules can be converted
to frozen module structures using tools/make-frozen.py script.

See issue #699.

Saves 24 bytes in bare-arm.

pyexec_friendly_repl_process_char() and friends, useful for ports which
integrate into existing cooperative multitasking system.

Unlike readline() refactor before, this was implemented in less formal,
trial&error process, minor functionality regressions are still known
(like soft&hard reset support). So, original loop-based pyexec_friendly_repl()
is left intact, specific implementation selectable by config setting.

This helps compiler produce smaller code.  Saves 124 bytes on stmhal and
bare-arm.

Previously was allocating at end of PASS_COMPUTE, and this pass was
being run twice, so memory was being allocated twice.

Bytecode also needs a pass to compute the stack size.  This is because
the state size of the bytecode function is encoded as a variable uint,
so we must know the value of this uint before we encode it (otherwise
the size of the generated code changes from one pass to the next).

Having an entire pass for this seems wasteful (in time).  Alternative is
to allocate fixed space for the state size (would need 3-4 bytes to be
general, when 1 byte is usually sufficient) which uses a bit of extra
RAM per bytecode function, and makes the code less elegant in places
where this uint is encoded/decoded.

So, for now, opt for an extra pass.

Native code has GC-heap pointers in it so it must be scanned.  But on
unix port memory for native functions is mmap'd, and so it must have
explicit code to scan it for root pointers.