Ditch editor's mapEditorScriptingExtension file or cut down on its size

[Dark-Dragon]

Is your feature request related to a problem? Please describe.
Currently certain features offered by the map editor (namely removal of world objects and the use of LOD models for objects) require a separate script file to be added with every map to make them function properly. This not only requires some code, but also a fairly large lookup table for objects and their associated LOD models to be added to the map resource. As of now this file is added regardless of whether the map uses any of the features that require the script extension file. The files currently add up to around 25kb for every single map. With the updated LOD table adding missing LODs from #556 the total would grow to 70kb per map. That's a large amount of storage space wasted if we consider that it's not uncommon for maps to total 40kb or many times much less in size.

Describe the solution you'd like
Ideally a separate resource (for instance mapmanager) that is included within MTA would step in to provide the missing functionality for all map resources that use these features, removing the need to add endless amounts of identical script files for every single map created with the default map editor. A simple "include" for said resource in the map resource's meta.xml should then be enough to ensure functionality.

Describe alternatives you've considered
If the above solution is somehow not deemed feasible, then we should at the very least try to cut down on the amount of junk we're packing with each map resource. The script extension file should only be added when necessary and only the necessary components should be added. IE if a map uses the remove world model feature but doesn't enable LOD models, then only the part of the script that is responsible for the removal of world objects should be added to the script file. Furthermore if LOD models are used, then the lookup table should only include the objects that the map uses rather than all the object IDs.

Feel free to come up with other alternative solutions, as I'm sure there are many ways to take on this issue with more style than the current implementation.

Additional context
Whatever solution we come up with, we also need to make sure we don't break the existing implementation for older maps. Since they all come with a script file and only future maps should be affected, I don't think we would run into many issues with this, unless we were to attempt to apply those changes retroactively, which I don't think is necessary or desirable.