fix segfault when length fields contain a big 32-bit number

When interpreting MessagePack 32-bit length fields, we incorrectly cast
to int; this causes a field length of "\xff\xff\xff\xff" to be
interpreted as -1, which is then casted to size_t as
18446744073709551615 (= max_uint64 - 1).

The fix makes sure that all the size arithmetic is done as size_t; and
prevents adding anything to a given size_t in order not to overflow
(even on 32-bit builds).
Merge pull request #36 from dubek/fix-big-32bit-len-segfault

fix segfault when length fields contain a big 32-bit number
Merge remote-tracking branch 'upstream/master'