Draft approach towards resolving https://github.com/micropython/micropython/issues/560#issuecomment-42213955

This is primarily intended to provide testing of Thumb-specific code within
Travis CI as well as if anyone else want to run it locally.  As discussed in
purposes.  This is currently agains an emulated Cortex-M3 core, however in
the near future it can extended to support M0, M0+ as well M4 (work in
progress exists in sushihangover/qemu).

It's probably true that most of the code base can be covered running uPy
natively on a POSIX system, however we do have the tiny bit of assembly
code.  There may exist bugs related to endianness and type aliases, let
alone potential standard library or compiler bugs or even
architecture-specific optimisations.

This could also incorporate lwIP (or other TCP/IP stack) integration as well
as SDIO+FATFS drivers.

The solution to inline the test cases was chose due to simplicity. It could
alternatively be implemented in a number of different way (see #515), but
this looked the simplest.

Inclusion of tinytest was just to avoid writing boilerplate code for
counting failed tests and other utility functions.  Currently only a few
functions are used, however this could be extended.  Checking in the code
instead of using submodule was a personal preference, but if people do want
the pain of submodules, this can provided.  This particular framework is
also pretty good if one desires to run unit test on target.  The approach
with scripts being inlined is probably not quite suited for the size of
memory an MCU has, but the tinytest itself should be good, if lower-level C
code is to be unit tested.

windows: Fix input.c missing in Makefile after changes for #582

Inspired by discussion in #577. So, in this case of builtin function,
passing args by keyword has less than 1% overhead.

Passing 3 args with keywords is for example 50% slower than via positional
args.

... and we have not that bad mapping type after all - lookup time is ~ the
same as in one-attr instance. My namedtuple implementation on the other
hand degrades awfully.

So, need to rework it. First observation is that named tuple fields are
accessed as attributes, so all names are interned at the program start.
Then, really should store field array as qstr[], and do quick 32/64 bit
scan thru it.

That's higher than instance field access - behold the power of hashing.

Just a start, no working code yet.  As per issue #573.

Add input command for unix

windows: Enable math module

Enable only on unix. To avoid unpleasant surprises with error codes.

In case of empty non-blocking read()/write(), both return None. read()
cannot return 0, as that means EOF, so returns another value, and then
write() just follows. This is still pretty unexpected, and typical
"if not len:" check would treat this as EOF. Well, non-blocking files
require special handling!

This also kind of makes it depending on POSIX, but well, anything else
should emulate POSIX anyway ;-).

Doesn't help with RAM reduction because doc strings are interned as soon
as they are encountered, which is too soon to do any optimisations on
them.

Conflicts:
	py/argcheck.c
	py/objenumerate.c
	py/runtime.h

Need to have a policy as to how far we go adding keyword support to
built ins.  It's nice to have, and gets better CPython compatibility,
but hurts the micro nature of uPy.

Addresses issue #577.

Addresses #567.

Addresses #577.

TODO: Get rid of this compatibility define and rely on standard module.

...to some compilers who can't process 2 zero-sized arrays in structs. It's
never referenced directly anyway.

See disussion on #568 as well.

Change references (in comments) of pyb.GPIO to be pyb.Pin

The documentation at http://micropython.org/doc/module/pyb/ExtInt should also be
updated.