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.

added SDdatalogger example

There are 2 locations in parser, and 1 in compiler, where memory
allocation is not precise.  In the parser it's the rule stack and result
stack, in the compiler it's the array for the identifiers in the current
scope.  All other mallocs are exact (ie they don't allocate more than is
needed).

This patch adds tuning options (MP_ALLOC_*) to mpconfig.h for these 3
inexact allocations.

The inexact allocations in the parser should actually be close to
logarithmic: you need an exponentially larger script (absent pathological
cases) to use up more room on the rule and result stacks.  As such, the
default allocation policy for these is now to start with a modest sized
stack, but grow only in small increments.

For the identifier arrays in the compiler, these now start out quite
small (4 entries, since most functions don't have that many ids), and
grow incrementally by 6 (since if you have more ids than 4, you probably
have quite a few more, but it wouldn't be exponentially more).

Partially addresses issue #560.

Also compared with method abstraction for accessing instance vars -
it's more than 3 times slower than accessing var directly.

Motivation is optimizing handling of various constructs as well as
understanding which constructs are more efficient in MicroPython.
More info: http://forum.micropython.org/viewtopic.php?f=3&t=77

Results are wildly unexpected. For example, "optimization" of range
iteration into while loop makes it twice as slow. Generally, the more
bytecodes, the slower the code.

This will work if MICROPY_DEBUG_PRINTERS is defined, which is only for
unix/windows ports. This makes it convenient to user uPy normally, but
easily get bytecode dump on the spot if needed, without constant recompiles
back and forth.

TODO: Add more useful debug output, adjust verbosity level on which
specifically bytecode dump happens.