Validator reports errors for subtree files that do not have buffers

[javagl]

The following is a valid subtree file:

{
  "tileAvailability": { "constant": 1 },
  "contentAvailability": [{ "constant": 1 }],
  "childSubtreeAvailability": { "constant": 0 }
}

But currently, the validator reports

{
  "date": "2024-07-02T20:06:01.422Z",
  "numErrors": 2,
  "numWarnings": 0,
  "numInfos": 0,
  "issues": [
    {
      "type": "ARRAY_LENGTH_MISMATCH",
      "path": "./specs/data/subtrees/validSubtreeNoBuffers.json/buffers",
      "message": "Array 'buffers' must have a length of at least 1, but the actual length is 0",
      "severity": "ERROR"
    },
    {
      "type": "ARRAY_LENGTH_MISMATCH",
      "path": "./specs/data/subtrees/validSubtreeNoBuffers.json/bufferViews",
      "message": "Array 'bufferViews' must have a length of at least 1, but the actual length is 0",
      "severity": "ERROR"
    }
  ]
}

for this.

The arrays must have a length of at least 1, but they are optional within a subtree file. Right now, they are erroneously defaulted to [] in the SubtreeValidator.

Fixing this is easy. But there are a few test cases to consider

• One where the buffers/bufferViews are omitted but one of the availabilities refers to a bitstream (buffer view). The error message would now be "The 'bitstream' property must be in [0,0), but is 0" in this case, but should rather be "The bitstream property may only be used when buffer views have been defined" or so
• One where the bufferViews are present, but the buffers is omitted. This should cause a special error message as well
• One where the buffers are present, but the bufferViews are omitted. There is nothing wrong with that on a spec level, but it should at least generate an INFO - I'd even say a WARNING...

There are a bunch of subtree test cases in the specs/data/subtrees folder. These are currently not validated as part of the unit tests. They can only be validated manually with the (internal) --subtreeSpecs command line function. One difficulty for validating subtree files in isolation (in the specs) is that they usually need structural information (i.e. the implicitTiling from the tileset) to be interpreted correctly. But still, the current spec files (which all use the same structural information) could be added. And the new ones (that will be created in the context of this issue) will exactly be those that do not require structural information.

(This is related to #226 in this regard - but since the file-based appraoch seems to work reasonably well, the same can be applied to the subtree spec files for now)