Allocate byte[] lazily for longer Smile binary data payloads (raw)

[cowtowncoder]

(from https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=32180)

Looks like eager allocation is used for Smile binary payload if using "raw"/native embedding.
Similar to #186, this should be only used for relatively short payloads to avoid potential for DoS by attacker specifying allegedly large data size but only sending minimal partial message (essentially just marker, length and maybe a bit or two)

[cowtowncoder]

The issue seems oddly resistant to reproduction: for some reason, allocating a 2-gig byte array succeeds despite my trying to limit heap to 0.5 gigs (for example).

[cowtowncoder]

Needed to add Surefire (junit) plugin configuration to limit heap for forked-off test process, now test fails as expected from command-line.