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).