mp_obj_t internal representation doesn't have to be a pointer to object,
it can be anything.

There's also a support for back-conversion in the form of MP_OBJ_UNCAST.
This is kind of optimization/status quo preserver to minimize patching the
existing code and avoid doing potentially expensive MP_OBJ_CAST over and
over. But then one may imagine implementations where MP_OBJ_UNCAST is very
expensive. But such implementations are unlikely interesting in practice.

This change is required to unbreak some CPython stdlib modules (as included
into micropython-lib).

Despite initial guess, this code factoring does not hamper performance.
In fact it seems to improve speed by a little: running pystone(1.2) on
pyboard (which gives a very stable result) this patch takes pystones
from 1729.51 up to 1742.16.  Also, pystones on x64 increase by around
the same proportion (but it's much noisier).

Taking a look at the generated machine code, stack usage with this patch
is unchanged, and call is tail-optimised with all arguments in
registers.  Code size decreases by about 50 bytes on Thumb2 archs.

Disabled by default.  Enabled on unix and stmhal ports.

"Base" should rather refer to "base type"."Base object for attribute
lookup" should rather be just "object".

Also, a case of common subexpression elimination.

Addresses issue #1160.

Given that there's already support for "fixed table" maps, which are
essentially ordered maps, the implementation of OrderedDict just extends
"fixed table" maps by adding an "is ordered" flag and add/remove
operations, and reuses 95% of objdict code, just making methods tolerant
to both dict and OrderedDict.

Some things are missing so far, like CPython-compatible repr and comparison.

OrderedDict is Disabled by default; enabled on unix and stmhal ports.

We already have branch for lookup->is_type == true, so here it's guaranteed
to be false.

These allow to fine-tune the compiler to select whether it optimises
tuple assignments of the form a, b = c, d and a, b, c = d, e, f.
Sensible defaults are provided.

This follows existing pattern for object constructor API and allows to
create memoryview objects e.g. in external modules.

Might be useful at least for memoryview hacks.

Just to reduce code size.  Messages are still to the point and
unambiguous.

Should only give an error on the last pass of the assembler, since
that's when we are certain about the branch size.

Addresses issue #1143.