glTF modifier: fixed case of raster overlays

[Julot94]

GltfModifier: made it compatible with raster overlays (the initial revision of Gltf modifier was just ignoring them - so as soon as a modification was re-triggered, any cut-out polygon applied to the model would just be lost)

• raster overlays (computed as post-process) need to be recomputed after the modification step.
• in the case of the re-apply path (see reapplyGltfModifier), we need to restore the initial tile bounding volume, because the post-process can lead to set an empty bounding volume, which would trigger plenty of false positive errors when re-running the post-process on the tile.
• for up-sampled tiles, the re-apply path consists in up-sampling the modified parent (and not run the modifier on the current up-sampled tile...)
• in the the re-apply path, we must take the result of the modification step into account: if the modification step fails (which can now happen in case of up-sampling...), we still keep the current model, but we should notify the next step to avoid a crash when trying to set null resources to the rendered tile
• added a shared-mutex in TileRenderContent to fix a potential crash when the game thread is replacing the parent tile's content (replaceWithModifiedModel) while a worker thread is currently up-sapling it for one of its children

[j9liu]

Thanks @Julot94! @kring would you be able to take a look when you get the chance? I think you'd have a deeper understanding of the sequencing/lifetime implications here