Conceptually it is part of code state, so let it be allocated in the same way
as the rest of state.

Addresses issue #1022.

This optimisation reduces the VM exception stack element (mp_exc_stack_t)
by 1 word, by using bit 1 of a pointer to store whether the opcode was a
FINALLY or WITH opcode.  This optimisation was pending, waiting for
maturity of the exception handling code, which has now proven itself.

Saves 1 machine word RAM for each exception (4->3 words per exception).
Increases stmhal code by 4 bytes, and decreases unix x64 code by 32
bytes.

This saves a lot of RAM for 2 reasons:

1. For functions that don't have default values, var args or var kw
args (which is a large number of functions in the general case), the
mp_obj_fun_bc_t type now fits in 1 GC block (previously needed 2 because
of the extra pointer to point to the arg_names array).  So this saves 16
bytes per function (32 bytes on 64-bit machines).

2. Combining separate memory regions generally saves RAM because the
unused bytes at the end of the GC block are saved for 1 of the blocks
(since that block doesn't exist on its own anymore).  So generally this
saves 8 bytes per function.

Tested by importing lots of modules:

- 64-bit Linux gave about an 8% RAM saving for 86k of used RAM.
- pyboard gave about a 6% RAM saving for 31k of used RAM.

This should pretty much resolve issue #50.

Addressing issue #50.

Code-info size, block name, source name, n_state and n_exc_stack now use
variable length encoded uints.  This saves 7-9 bytes per bytecode
function for most functions.

Because (for Thumb) a function pointer has the LSB set, pointers to
dynamic functions in RAM (eg native, viper or asm functions) were not
being traced by the GC.  This patch is a comprehensive fix for this.

Addresses issue #820.

See discussion in issue #50.

This reduces stack usage by 16 words (64 bytes) for stmhal/ port.

See issue #640.

This improves stack usage in callers to mp_execute_bytecode2, and is step
forward towards unifying execution interface for function and generators
(which is important because generators don't even support full forms
of arguments passing (keywords, etc.)).

bytecode is the more widely used.  See issue #590.

Blanket wide to all .c and .h files.  Some files originating from ST are
difficult to deal with (license wise) so it was left out of those.

Also merged modpyb.h, modos.h, modstm.h and modtime.h in stmhal/.

Iterators and ducktype objects can now be arguments of yield from.

Required to reraise correct exceptions in except block, regardless if more
try blocks with active exceptions happen in the same except block.

P.S. This "automagic reraise" appears to be quite wasteful feature of Python
- we need to save pending exception just in case it *might* be reraised.
Instead, programmer could explcitly capture exception to a variable using
"except ... as var", and reraise that. So, consider disabling argless raise
support as an optimization.

Rationale: setting up the stack (state for locals and exceptions) is
really part of the "code", it's the prelude of the function.  For
example, native code adjusts the stack pointer on entry to the function.
Native code doesn't need to know n_state for any other reason.  So
putting the state size in the bytecode prelude is sensible.

It reduced ROM usage on STM by about 30 bytes :)  And makes it easier to
pass information about the bytecode between functions.

Based on issues raised during recent review and inconsistency of different
implementations.

This is required to properly handle exceptions across yields.

Addresses issue #290, and hopefully sets up things to allow generators
throwing exceptions, etc.

Exceptions know source file, line and block name.

Also tidy up some debug printing functions and provide a global
flag to enable/disable them.

Byte code has a map from byte-code offset to source-code line number,
used to give better error messages.

A big change.  Micro Python objects are allocated as individual structs
with the first element being a pointer to the type information (which
is itself an object).  This scheme follows CPython.  Much more flexible,
not necessarily slower, uses same heap memory, and can allocate objects
statically.

Also change name prefix, from py_ to mp_ (mp for Micro Python).