Add an optional glTF model modification stage after tile loading

[GhisBntly]

• Rationale:
  • Because a glTF primitive translates to a UStaticMesh instance, shaded by a single material instance derived from the base material, customizing the shading is limited by the tileset provider's decisions regarding the grouping/merging of geometries into glTF primitives. When using per-vertex metadata to customize the shading, some faces of a single primitive, thus sharing the same material instance, may require incompatible material settings.
  • A processing stage at the end of the tile loading process allows to generate new primitives representing the same geometry that can be shaded as intended.
  • Another use case could be to optimize rendering of tilesets which geometry has been split into too many primitives, by merging them into more efficient larger primitives.
• Implementation:
  • The tuner is a simple interface which implementation is left to users of this extension, because supplying a generic implementation supporting the full glTF specification is a complex task and could be a performance bottleneck.
  • The tuner has a version to tag each processed model, to allow the processing strategy to evolve over time depending on application logic. Outdated models are thus automatically reprocessed.
  • The code supplied in this PR applies the tuning process in two situations:
    • On a newly loaded tile, before it can be considered for display, to avoid any visual glitch,
    • On already loaded tiles, after the tuner version has been incremented.
• Limitation:
  • For simplicity, the consistency of the tileset after the tuner version has been incremented is not enforced: models corresponding to different tuner versions may coexist for as long as it will take to reprocess all outdated models.