vm: Introduce structure for exception stack entry, record entry type.

rt_call_function_n_kw did check for integers but not for strings
being called. Added a check so running "a"() won't SIGSEV but
throw an exception.

It's mildly suprising these work without further changes to exception
handling code (the only change required was to handle SETUP_FINALLY).

Also, handle SETUP_FINALLY opcode.

vm: Add basic implementation of END_FINALLY opcode.

windows: Make windows/main.c independent from unix/main.c

Up to know changes unix/main.c were able to break the windows
build because windows/main.c simply included unix/main.c.

Now windows/main.c stands on it's own and won't break if
unix/main.c changes.

Allows to have nested try blocks with except filters.

TODO: Don't add END_FINALLY's exception re-raise points to traceback.

Implement __bool__ and __len__ via unary_op virtual method for all types.

__bool__() and __len__() are just the same as __neg__() or __invert__(),
and require efficient dispatching implementation (not requiring search/lookup).
type->unary_op() is just the right choice for this short of adding
standalone virtual method(s) to already big mp_obj_type_t structure.

To alloc complete memory alloc flow tracing.

We still have FAST_[0,1,2] byte codes, but they now just access the
fastn array (before they had special local variables).  It's now
simpler, a bit faster, and uses a bit less stack space (on STM at least,
which is most important).

The only reason now to keep FAST_[0,1,2] byte codes is for compressed
byte code size.

LOAD_METHOD bug was: emitbc did not correctly calculate the amount of
stack usage for a LOAD_METHOD operation.

small int bug was: int was being used to pass small ints, when it should
have been machine_int_t.

* Add SD card test to fix warning

* Remove include mpconfigport.h from file.c

* Issue #232

On my machine, 'import array' in CPython tries to load the array test.