Follow-up for empty MAXAR and VRICON validators

[javagl]

This builds upon #330 :

It contains a minor generalization that is related to the handling of extensions that allow certain content types: The 3D Tiles Tools already offer a functionality to detect a ContentDataType. And this functionality is now used for tracking the extension usage: When the content data type is determined to be CONTENT_TYPE_GLTF, ...GLB, ...3TZ, or ...GEOJSON, then this is tracked as the 3DTILES_content_gltf, MAXAR_content_3tz, and MAXAR_content_geojson being used. (The change starts here). In this context, I also did a minor cleanup of replacing the data type strings with the corresponding constants.

It also adds very basic specs for the changes from #330 - right now, these specs are basically only checking that using one of these extensions does not cause the message that said that the extension was not supported. These specs can serve as a "stub"/basis for the case where full validation of these extensions is added later.

[javagl]

I added some fixes for 3TZ validation. This is strictly speaking no longer part of the "follow-up" of the content handling, and could have warranted another PR. But it is related to aspects of the 3TZ validation that I noticed in the context of this PR:

When a 3TZ content was referred to with a relative path (i.e. example/path/file.3tz instead of file.3tz), then it caused a validation error, because it tried to resolve that path twice (looking for example/path/example/path/file.3tz).

(There are some intricacies for 3TZ: It is tile content, but also an "external tileset", and it always has to be resolved to an absolute path - because it always is a file in the local file system...)

Also, there had been no dedicated tests for tilesets with 3TZ content. Now there are three of them:

• A tileset with a valid 3TZ
• A tileset with a 3TZ that contains a tileset that contains an error
• A tileset with a 3TZ that is completely invalid

The last one covers one aspect that was fixed here as well: When the 3TZ was completely invalid, then the validation bailed out with an INTERNAL_ERROR. Now, it causes an IO_ERROR saying Failed to open ${uri}. Input file is invalid. (more specific messages are possible and exist for other file types, but not for 3TZ).

[javagl]

This has now been tested more extensively with real-world data, serves as the base state for #332 , and should therefore be ready for review.