Stacked processing of triggerdata.txt for GUI trigger regeneration

[Luashine]

I suppose Drake53's lib doesn't support this but here's the basic idea. The GUI trigger definitions are loaded by the game from 2 files: ai-somethingsomething.txt (for AI Editor) and triggerdata.txt (the main GUI editor). These files are completely declarative to the WorldEditor and some WE mods over the years have expanded these files to add new trigger functions (much like Reforged itself did with new game APIs).

It's possible map creators used these custom WE mods and unless the correct triggerdata.txt was loaded, the GUI regeneration wouldn't recognize these functions in code as triggers. To be frank, vanilla WE wouldn't either. Though another mod that'll gain traction is GrapesOfWath's GuiGui - this program provides a nice interface to add custom triggerdata and I assume at some point his default triggerdata distribution will become somewhat popular. Another triggerdata mod I know of is YDWE (probably more in Chinese community) and probably one or two from the Russian community.

For the purposes of adding to jassdoc, I wrote my own triggerdata parser and with the above requirements in mind, I intend to add "stacked" processing of triggerdata, when multiple definitions are specified, they are processed and merged together to form one output. I'll call it a stacked approach, because with the __index metatable in Lua it's easy fall through to underlying tables that do hold the data, which is missing from a higher up table.

That tool in its current form is not ready to be used as a library in any form other than a CLI.

The alternative: the advantages of going all this way, is to restore the map to the point as it was when the original author was making it in modded WE. Obviously this is not required and all unrecognized trigger code could simply be made into "custom code". Modified triggerdata is not openable/workable in the vanilla editor anyway.

But if given the choice, the user could decide if s/he wants vanilla triggers or custom triggers with a notice which WE mod to use. Some simple counting (how many modded triggers found) would be needed to avoid false-positives, like one real custom code function recognized as modded triggerdata.

The need for this could be evaluated while scanning the current map corpus.