Examine the effects of 'semantics' for the validation

**tl;dr**: The 'semantics' for metadata may cause certain tileset properties to be 'overridden'. It is not clear how this affects the validity of tilesets.

---

There is a set of predefined [semantics for metadata properties](https://github.com/CesiumGS/3d-tiles/tree/80cfa97f3c5dd7e1b7a830daae81f3ab866a29fd/specification/Metadata/Semantics). In some cases, these may just be a "name" for a certain type of additional information. In other cases, these semantics are supposed to essentially _override_ existing properties. For example, when a tile has a property with the `TILE_BOUNDING_BOX` semantic, then this overrides the `tile.boundingVolume.box`.

This raises some questions for the validation. The semantics are decoupled from the 3D Tiles specification itself. They are supposed to be defined and used by certain _applications_. Therefore, they can hardly be integrated into the validator _generically_.

For example, the specification says that the `tile.boundingVolume` must enclose all the contents. When the validator is supposed to check this, then it would determine the bounding volume of the contents, and check whether it is contained in the `tile.boundingVolume`. If this is not the case, an 'error' will be generated. But the tile may have a property with the `TILE_BOUNDING_BOX` semantic, and maybe this bounding volume **is** valid. It is not clear how this is supposed to be handled by the validator. The semantics do not _define_ the overridden property in a "machine-processable" sense, but only via a statement in their description. (And there is no limit in which meaning a third-party application _could_ assign to their third-party semantics...)

With some effort, a special treatment could be added manually, for the semantics that are currently known. But even there, the effect that this will have on the _validity_ of a tileset will have to be examined carefully. Referring to the example above: When there is an invalid `tile.boundingVolume`, then this is an 'error'. But when there is a `TILE_BOUNDING_BOX` semantic, then this 'error' might become a 'warning'. Completely omitting it would classify the tileset to be 'valid', but it wouldn't be valid according the the core specification - or for an _application_ that is not aware of the `TILE_BOUNDING_BOX` semantic...

Review the validator's existing tile bounding-volume checks and its handling of metadata semantics, then compare them with the linked semantics definitions and core specification. Define whether known or third-party semantics alter validation results and what the completed behavior should be; the issue names no implementation files or tests, so those must be located first.

Written by the indexing model from the issue text.