The inline docs (prefixed with /// in .c files) have been converted to
RST format and put in the docs subdirectory.

This is experimental support.  API is subject to changes.  RTS/CTS
available on UART(2) and UART(3) only.  Use as:

    uart = pyb.UART(2, 9600, flow=pyb.UART.RTS | pyb.UART.CTS)

This patch also enables non-blocking streams on stmhal port.

One can now make a USB-UART pass-through function:

def pass_through(usb, uart):
    while True:
        select.select([usb, uart], [], [])
        if usb.any():
            uart.write(usb.read(256))
        if uart.any():
            usb.write(uart.read(256))

pass_through(pyb.USB_VCP(), pyb.UART(1, 9600))

msvc does not treat 1L a 64bit integer hence all occurences of shifting it left or right
result in undefined behaviour since the maximum allowed shift count for 32bit ints is 31.
Forcing the correct type explicitely, stored in MPZ_LONG_1, solves this.

Original motivation is to support converting bytearrays, but easier to just
support buffer protocol at all.

It should be fair to say that almost in all cases where some API call
expects string, it should be also possible to pass byte string. For example,
it should be open/delete/rename file with name as bytestring. Note that
similar change was done quite a long ago to mp_obj_str_get_data().

Because bytearrays are much friendlier to work with, e.g. they can be printed
easily.

Before, sizeof() could be applied to a structure field only if that field
was itself a structure. Now it can be applied to PTR and ARRAY fields too.
It's not possible to apply it to scalar fields though, because as soon as
scalar field (int or float) is dereferenced, its value is converted into
Python int/float value, and all original type info is lost. Moreover, we
allow sizeof of type definitions too, and there int is used to represent
(scalar) types. So, we have ambiguity what int may be - either dereferenced
scalar structure field, or encoded scalar type. So, rather throw an error
if user tries to apply sizeof() to int.

Use it like:

make CFLAGS_EXTRA='-DMP_CONFIGFILE="<mpconfigport_my.h>"'

Also, move bytecode dumps to -v -v, because they're too verbose for just -v.

Eg: dac = DAC(Pin.board.X5)

Support for packages as argument not implemented, but otherwise error and
exit handling should be correct. This for example will allow to do:

pip-micropython install micropython-test.pystone
micropython -m test.pystone

Improvements are:

2 ctrl-C's are now needed to truly kill running script on pyboard, so
make CDC interface allow multiple ctrl-C's through at once (ie sending
b'\x03\x03' to pyboard now counts as 2 ctrl-C's).

ctrl-C in friendly-repl can now stop multi-line input.

In raw-repl mode, use ctrl-D to indicate end of running script, and also
end of any error message.  Thus, output of raw-repl is always at least 2
ctrl-D's and it's much easier to parse.

pyboard.py is now a bit faster, handles exceptions from pyboard better
(prints them and exits with exit code 1), prints out the pyboard output
while the script is running (instead of waiting till the end), and
allows to follow the output of a previous script when run with no
arguments.

Was 1 or 2, now 0 or 1 (respectively).  0 means sample MISO on first
edge, 1 means sample on second edge.

Addresses issue #936.

This way, if original parent object is GC'd, the memoryview still points
to the underlying buffer data so that buffer is not GC'd.

This allows to implement KeyboardInterrupt on unix, and a much safer
ctrl-C in stmhal port.  First ctrl-C is a soft one, with hope that VM
will notice it; second ctrl-C is a hard one that kills anything (for
both unix and stmhal).

One needs to check for a pending exception in the VM only for jump
opcodes.  Others can't produce an infinite loop (infinite recursion is
caught by stack check).

This gets CDC+HID working on Windows, since it needs a different PID for
a different USB configuration.

Thanks to tmbinc and dhylands.

This should be pretty compliant with CPython, except perhaps for some
corner cases to do with globals/locals context.

Addresses issue #879.

There is a lot potential in compress bytecodes and make more use of the
coding space.  This patch introduces "multi" bytecodes which have their
argument included in the bytecode (by addition).

UNARY_OP and BINARY_OP now no longer take a 1 byte argument for the
opcode.  Rather, the opcode is included in the first byte itself.

LOAD_FAST_[0,1,2] and STORE_FAST_[0,1,2] are removed in favour of their
multi versions, which can take an argument between 0 and 15 inclusive.
The majority of LOAD_FAST/STORE_FAST codes fit in this range and so this
saves a byte for each of these.

LOAD_CONST_SMALL_INT_MULTI is used to load small ints between -16 and 47
inclusive.  Such ints are quite common and now only need 1 byte to
store, and now have much faster decoding.

In all this patch saves about 2% RAM for typically bytecode (1.8% on
64-bit test, 2.5% on pyboard test).  It also reduces the binary size
(because bytecodes are simplified) and doesn't harm performance.