Updated functions now do proper checking that n_kw==0, and are simpler
because they don't have to explicitly raise an exception.  Down side is
that the error messages no longer include the function name, but that's
acceptable.

Saves order 300 text bytes on x64 and ARM.

Likely there are other functions that should be renamed, but this is a
start.

For consistency with MICROPY_MOD_SYS_STDFILES, etc.

This is not fully correct re: error handling, because we should check that
that types are used consistently (only str's or only bytes), but magically
makes lot of functions support bytes.

Two things are handled here: allow to compare native subtypes of tuple,
e.g. namedtuple (TODO: should compare type too, currently compared
duck-typedly by content). Secondly, allow user sunclasses of tuples
(and its subtypes) be compared either. "Magic" I did previously in
objtype.c covers only one argument (lhs is many), so we're in trouble
when lhs is native type - there's no other option besides handling
rhs in special manner. Fortunately, this patch outlines approach with
fast path for native types.

This was hit when trying to make urlparse.py from stdlib run. Took
quite some time to debug.

TODO: Reconsile bound method creation process better, maybe callable is
to generic type to bind at all?

Similar to closure and cell.

Slice value to assign can be only a list so far too.

Includes support for native bases.

Happens regularly when used for debugging.

Thumb uses a bit less RAM, bytecode uses a tiny bit more, to avoid
overflow of the dummy buffer in certain cases.

Addresses issue #599.

Parser shouldn't raise exceptions, so needs to check when memory
allocation fails.  This patch does that for the initial set up of the
parser state.

Also, we now put the parser object on the stack.  It's small enough to
go there instead of on the heap.

This partially addresses issue #558.

Takes 416 text bytes on x86.

Tired of patching CPython stdlib for it.

"object" type in MicroPython currently doesn't implement any methods, and
hopefully, we'll try to stay like that for as long as possible. Even if we
have to add something eventually, look up from there might be handled in
adhoc manner, as last resort (that's not compliant with Python3 MRO, but
we're already non-compliant). Hence: 1) no need to spend type trying to
lookup anything in object; 2) no need to allocate subobject when explicitly
inheriting from object; 3) and having multiple bases inheriting from object
is not a case of incompatible multiple inheritance.

This patch simplifies the glue between native emitter and runtime,
and handles viper code like inline assember: return values are
converted to Python objects.

Fixes issue #531.

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

Should support everything supported by strings.

So one has some chance to convert numeric op code into symbol.

You can now do:

    X = const(123)
    Y = const(456 + X)

and the compiler will replace X and Y with their values.

See discussion in issue #266 and issue #573.