[FR] Extend unsynced heightmap to other map-related stuff

Currently there's two heightmaps, synced and unsynced. All changes (deformation via explosions or flattening under buildings, Lua callouts etc) apply to the synced heightmap; data from the synced heightmap is propagated to the unsynced heightmap if the client has read access (specs always do, players require sight), and what the client sees (via rendering, or Lua callouts like `Spring.GetGroundHeight`) is the unsynced heightmap.

The request is to expand this "two copies, reveal truth in LoS" scheme to other things related to the map. Note that for textures it wouldn't be "truly" synced since it's just a texture, and it would be drawn by unsynced LuaRules (since synced LuaRules has no facilities for that), the term "synced" only means that there is a source of truth that is there in the background but not directly visible, only through the "unsynced" imperfect view.
* diffuse texture (i.e. the "main" terrain texture). The immediate use case is for ZK terraform texture, we currently have some complicated handler that tries to keep track of what needs to be applied and only actually apply it in LoS ( ZeroK-RTS/Zero-K#4889 ). The cooler one that becomes enabled down the road would be the "classic" black fog of war that needs to be explored to reveal the terrain (there's some prior work by gajop apparently, see https://springrts.com/phpbb/viewtopic.php?t=33703 ).
* ideally this would involve all the PBR shading stuff like splat maps, specular etc since else the black area randomly has shiny parts (note that the synced ones would not be actually drawn, only used for being copied to the unsynced texture, so perhaps this wouldn't be as expensive as it sounds, but I'm a layman here).
* non-texture stuff local to map areas, like typemap, building masks, metalmap or grass. Currently we can't do things like cut grass under buildings or apply speedboosts on zerg creep without also revealing that there is something there, because you can see the missing square of grass globally. Here "synced" actually means synced.

Begin by tracing the existing synced-to-unsynced heightmap propagation and the rendering and visibility paths described in the issue. Review how synced and unsynced LuaRules handle map data; done would mean a coherent design and implementation covering the requested terrain textures, shading data, and local map-area data without revealing hidden information.

Written by the indexing model from the issue text.