Bigger integers in generators show failing tests

Show failing test for issue #5

* Make `big()` generate bigger numbers
* Add `big()` to `simple_types/0`
* Increase number of tests to 2000 (the `prop_sort` test was not
consistently failing at 1k tests)

This commit should show that there are current three failures with
bigger integers: `prop_sort`, `prop_sort_sb32` and `prop_sort_hex`.

Note this file also seems to use Windows (CRLF) line endings, so I continued
in that fashion.
INCOMPATIBILITY: changed encoding of bignums

Bignums were encoded in a way that didn't preserve the sorting property.

To fix this, I have prepended a length indicator. In order to be
able to read legacy-encoded bignums, I made use of the fact that
the first byte returned in the return value from encode_big1/1
was never > 254. Thus, 255 is used to indicate the new format. I.e.
<<11, 255, ...length indicator..., ...encoded bignum...>>

The length indicator gives the number of bytes, and will usually
be one byte long. If the number of bytes is > 127, the length
indicator will be encoded as a sequence of 7-bit "septets", where
each except the last is tagged with 1 in the MSB.

The decode function removes the size indicator, and also recognizes
that if the first byte is =< 254, there is no size indicator,
and decodes a legacy bignum.

This means that a data set can be converted by simply decoding and
encoding each value.

For further backwards compatibility, the function
sext:legacy_encode_bignum/1 encodes a bignum in the old format.