Align Lua and client editing functions
Client editing mode and Lua edit methods work basically in the same moments. So we have a code to edit the game but part of it has one interface and another part has another interface, and not all possibilities are represented in both ways. Maybe some code under packet processing and Lua API is unnecessary doubled.
Added sub-tickets #42681 #42682 #42683 #42684. Also, may be considered depending on #42502.
Editing scenario strings by Lua may be considered not useful so no ticket for it here. Maybe we should also have a function to set game year that is not in mentioned tickets.
Note: I, with notable probability, will make myself the missing Lua API, but hardly will enhance the client editing interface.
Common note for all API sub-tickets: each call to a separate editing function requires sending packets to clients. It looks like the packets won't be glued together by the net buffer, so, if you add 10 buildings to a city and rename it, you send 11 packets. That is less effective than client editor mechanism that gets a single special edit packet, changes its fields and sends it back, then update happens once for one object. What can be done:
a) We make classes for editing packets, append to each game class server API :edit() method that loads one into Lua memory, then we edit it and use :apply(X_Edit_Obj modified). Obvious pluses: easy to make, one edit object can be applied to several cities etc. Minuses: the API is inopaque and more visible edit methods must be done separately.
b) Make it possible to freeze dispatching info to clients from Lua code, force to unfreeze back when a callback ends. But developing single methods (and coding some other stuff) is mandatory, cloning needs a special mechanism, and a ruleset author easily forgets to use freezing before overwriting the whole map.
I currently incline to (a) but maybe some parts of (b) may be also done if it proves easy enough.