Errors beget more errors

I think this is a common problem for compilers and such. Once a "real" error sends parsing off the rails, additional follow-on errors may not be on-target.

One example:

https://github.com/KhronosGroup/glTF-Sample-Models/blob/e6c0057a26f58c4f72cfa3b264ee0df281cc1a7b/2.0/DamagedHelmet/glTF/DamagedHelmet.gltf#L29

Change `"VEC3"` to `"VEC3x"` and run the validator:

> Invalid value 'VEC3x'. Valid values are...

Correct!

> Invalid accessor format '{null, FLOAT}' for this attribute semantic. Must be one of ('{VEC3, FLOAT}').

Well, yes, this `POSITION` is invalid in that it references an invalid `accessor`, so, I guess this is OK, but it's not where the problem is.

> accessor.min and accessor.max must be defined for POSITION attribute accessor.

No, `min` and `max` are certainly defined for this `accessor`.

Let's try another example:

https://github.com/KhronosGroup/glTF-Sample-Models/blob/e6c0057a26f58c4f72cfa3b264ee0df281cc1a7b/2.0/NormalTangentTest/glTF/NormalTangentTest.gltf#L22

Change `"mesh": 0` to `"mesh": 50`.

> Unresolved reference: 50.

Correct!

> Empty node encountered.

No, the node contains only an invalid reference, but it's certainly not empty.

Reproduce the two malformed glTF examples linked in the issue and inspect the validator paths that emit the follow-on diagnostics. Done means invalid accessor formats and unresolved mesh references do not produce misleading errors about dependent data such as min/max or empty nodes.

Written by the indexing model from the issue text.