Uncaught validation problem wrt Smile "BigDecimal" type (found by OSS-Fuzzer)

[cowtowncoder]

(note: offshoot of this finding https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=32168)

Looks like following 7-byte document encoding a single "BigInteger" value:

0x3A 0x29 0x0A  0x08  // 4 byte header (note, 0x8 specifies unused bit that... maybe should error)
0x2A // Number, BigDecimal
0xFF // scale; zigzag value of -32,
   // HOWEVER, not actually legal as second-most-significant-bit SHOULD be zero
   // (should this be caught, reported?)
   // -- should be 0xBF
0xC0 // length of payload, zigzag of 0 but similarly invalid represention
   // -- should be 0x80

causes an exception within BigInteger, attempting to pass 0-byte array to construct BigInteger (to further create BigDecimal). That is not a valid value and needs to be specifically checked against, reported.

[cowtowncoder]

One change for more robust handling: allow zero-length payload for BigInteger (value, or unscaled part) to represent BigInteger.ZERO and BigDecimal.ZERO respectively. Since rules regarding this particular potential encoding were not spelled out, seems safest to do this instead of exception.