`DataInput` backed parser should handle `EOFException` at end of doc

[bdhess]

Found while implementing #323.

java.io.IOException: End-of-input for readByte()

    at com.fasterxml.jackson.core.testsupport.MockDataInput.readByte(MockDataInput.java:45)
    at com.fasterxml.jackson.core.testsupport.MockDataInput.readUnsignedByte(MockDataInput.java:52)
    at com.fasterxml.jackson.core.json.UTF8DataInputJsonParser._skipWS(UTF8DataInputJsonParser.java:2177)
    at com.fasterxml.jackson.core.json.UTF8DataInputJsonParser.nextToken(UTF8DataInputJsonParser.java:572)
    at com.fasterxml.jackson.core.read.TrailingCommasTest.testStandardArray(TrailingCommasTest.java:50)

Test code:

        String json = "[\"a\", \"b\"]";
        JsonParser p = createParser(new JsonFactory(), MODE_DATA_INPUT, json);

        assertEquals(JsonToken.START_ARRAY, p.nextToken());
        assertToken(JsonToken.VALUE_STRING, p.nextToken());
        assertEquals("a", p.getText());
        assertToken(JsonToken.VALUE_STRING, p.nextToken());
        assertEquals("b", p.getText());
        assertEquals(JsonToken.END_ARRAY, p.nextToken());
        assertNull(p.nextToken());  // throws

[cowtowncoder]

This is actually a feature of DataInput as a source, which has no concept of returning anything at the end of input -- it can only throw an exception. So there isn't any way around that, that I know of.
Tests work around this in various ways.

[bdhess]

DataInput's contract says it throws an EOFException at the end of stream. So that could be caught and coerced to null. That behavior is actually implied by the documentation for UTF8DataInputJsonParser.nextToken():

Returns:
Next token from the stream, if any found, or null to indicate end-of-input

[cowtowncoder]

Hmmh. I guess that'd be possible, although it would lead to rather inefficient behavior (since exceptions are rather costly on modern JVMs). I'll have to think about this.
On plus side, default handling by ObjectMapper does not read more than what is needed, so this would only be triggered by code that does look for end-of-input; so overhead is avoidable.

Javadoc does predate addition of DataInput, but it would definitely be nice to keep things consistent.

[cowtowncoder]

Ok: I added handling at place where it should handle the common case of end-of-input at root level (not within JSON Object or Array), and that should allow proper handling of common case. And remaining other problem cases should result in IOException that is close enough to optimal; trying to handle those would be much more complicated with diminishing returns.