With this patch the n_args parameter is changed type from mp_uint_t to
size_t.

This allows the mp_obj_t type to be configured to something other than a
pointer-sized primitive type.

This patch also includes additional changes to allow the code to compile
when sizeof(mp_uint_t) != sizeof(void*), such as using size_t instead of
mp_uint_t, and various casts.

This makes format specifiers ~ fully compatible with CPython.

Adds 24 bytes for stmhal port (because previosuly we had to catch and report
it's unsupported to user).

Previous to this patch, a big-int, float or imag constant was interned
(made into a qstr) and then parsed at runtime to create an object each
time it was needed.  This is wasteful in RAM and not efficient.  Now,
these constants are parsed straight away in the parser and turned into
objects.  This allows constants with large numbers of digits (so
addresses issue #1103) and takes us a step closer to #722.

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.

Addresses issue #1022.

This is just a clean-up of the code.  Generated code is exactly the
same.

Addressing issue #50.

Part of code cleanup, working towards resolving issue #50.

See discussion in issue #50.

It defines types used by all other headers.

Fixes #691.

Also, add comment with description of extension to CPython's typecodes.

Now of the form MICROPY_PY_*.  See issue #35.

Infra for counts of other types is there, need last mile to be implemented.

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

When querying an object that supports the buffer protocol, that object
must now return a typecode (as per binary.[ch]).  This does not have to
be honoured by the caller, but can be useful for determining element
size.

Only calcsize() and unpack() functions provided so far, for little-endian
byte order. Format strings don't support repition spec (like "2b3i").

Unfortunately, dealing with all the various binary type sizes and alignments
will lead to quite a bloated "binary" helper functions  - if optimizing for
speed. Need to think if using dynamic parametrized algos makes more sense.