Some small code clean-ups that result in about 80 bytes ROM saving for
stmhal.

Multiplication of a tuple, list, str or bytes now yields an empty
sequence (instead of crashing).  Addresses issue #799

Also added ability to mult bytes on LHS by integer.

Also disable gc module on bare-arm port.

Can now index ranges with integers and slices, and reverse ranges
(although reversing is not very efficient).

Not sure how useful this stuff is, but gets us closer to having all of
Python's builtins.

reversed function now implemented, and works for tuple, list, str, bytes
and user objects with __len__ and __getitem__.

Renamed mp_builtin_len to mp_obj_len to make it publically available (eg
for reversed).

Saves code bytes and makes it faster, so why not?

Fixes #795.

Similar to other methods and following CPython3 strictness.

This happens for example for zero-size arrays. As .get_buffer() method now
has explicit return value, it's enough to distinguish success vs failure
of getting buffer.

This was a nasty bug to track down.  It only had consequences when the
heap size was just the right size to expose the rounding error in the
calculation of the finaliser table size.  And, a script had to allocate
a small (1 or 2 cell) object at the very end of the heap.  And, this
object must not have a finaliser.  And, the initial state of the heap
must have been all bits set to 1.  All these conspire on the pyboard,
but only if your run the script fresh (so unused memory is all 1's),
and if your script allocates a lot of small objects (eg 2-char strings
that are not interned).

Before this patch, eg, 1 << 75 (or any large multiple of 15) was setting
the MSB in the digits, which is outside the valid range of DIG_MASK.

qstr_init is always called exactly before mp_init, so makes sense to
just have mp_init call it.  Similarly with
mp_init_emergency_exception_buf.  Doing this makes the ports simpler and
less error prone (ie they can no longer forget to call these).

Reduces by about a factor of 10 on average the amount of RAM needed to
store the line-number to bytecode map in the bytecode prelude.

Using CPython3.4's stdlib for statistics: previously, an average of
13 bytes were used per (bytecode offset, line-number offset) pair, and
now with this improvement, that's down to 1.3 bytes on average.

Large RAM usage before was due to some very large steps in line numbers,
both from the start of the first line in a function way down in the
file, and also functions that have big comments and/or big strings in
them (both cases were significant).

Although the savings are large on average for the CPython stdlib, it
won't have such a big effect for small scripts used in embedded
programming.

Addresses issue #648.

This removes mpz_as_int, since that was a terrible function (it
implemented saturating conversion).

Use mpz_as_int_checked and mpz_as_uint_checked.  These now work
correctly (they previously had wrong overflow checking, eg
print(chr(10000000000000)) on 32-bit machine would incorrectly convert
this large number to a small int).

Addresses issue #724.

This allows to create str's with a smaller length than initially asked
for.

Lexer is now 8-bit clean inside strings.

Many OSes/CPUs have affinity to put "user" data into lower half of address
space. Take advantage of that and remap such addresses into full small int
range (including negative part).

If address is from upper half, long int will be used. Previously, small
int was returned for lower quarter of address space, and upper quarter. For
2 middle quarters, long int was used, which is clearly worse schedule than
the above.

The user code should call micropython.alloc_emergency_exception_buf(size)
where size is the size of the buffer used to print the argument
passed to the exception.

With the test code from #732, and a call to
micropython.alloc_emergenncy_exception_buf(100) the following error is
now printed:
```python
>>> import heartbeat_irq
Uncaught exception in Timer(4) interrupt handler
Traceback (most recent call last):
  File "0://heartbeat_irq.py", line 14, in heartbeat_cb
NameError: name 'led' is not defined
```

Addresses issue #765.

With this fix, file_long_read now passes.

And not system printf(), like it was before. For this, move pfenv_printf()
from stmhal port to py/.

With unicode enabled, this patch allows reading a fixed number of
characters from text-mode streams; eg file.read(5) will read 5 unicode
chars, which can made of more than 5 bytes.

For an ASCII stream (ie no chars > 127) it only needs to do 1 read.  If
there are lots of non-ASCII chars in a stream, then it needs multiple
reads of the underlying object.

Adds a new test for this case.  Enables unicode support by default on
unix and stmhal ports.

Addresses issue #753.