`UnitDefs[x].iconType` has different behaviour to other tags

`Spring.SetUnitDefIcon` is an unsynced ctrl callout which can be used to change a unitdef's default icon type.

The unique thing about it is that this gets immediately reflected in the unit def itself, which is unlike any other tag (others are all constant outside `/editdefs` which matters for caching etc) and necessitates an `if synced` check which is also unique (apparently all[^1] other def tags are readable from both synced and unsynced).

It would be good if the tag worked like any other, i.e. was immutable and available from synced. In particular, this is how the similar unitdef tag for buildpic works (you can change the buildpic, but the unitdef always shows the original, which is also good for the ability to go back to the default even if you override). Make sure the value is still accessible somehow.

https://github.com/beyond-all-reason/RecoilEngine/blob/6d2b7e9c758590ecb596f77d29f924546479149e/rts/Lua/LuaUnitDefs.cpp#L277-L286

[^1]: apparently sound set has a soundID entry for unsynced only. Would be nice to handle that one too but I have no idea how. Maybe there's other tags like that too, at a cursory glance I didn't find any though.

Start in rts/Lua/LuaUnitDefs.cpp around lines 277-286 and trace how UnitDefs[x].iconType is exposed and changed by Spring.SetUnitDefIcon. Compare it with the buildpic unitdef tag, then define the behavior so the tag remains immutable and readable from synced code while the changed value remains accessible through another path.

Written by the indexing model from the issue text.