JSInterface GUIPage - Allow parent GUI page to update a child GUI page

[elexis]

In some cases, a GUI page opens a child GUI page, and the information on that child page has to be updated if an event in the parent GUI page was handled.

For example in r18078 / ​Phab:rP18078#inline-2604 added that the AI configuration dialog is updated with the new settings if the host has changed the settings.

Another example would be the network window #3787 that has to be updated whenever g_GameAttributes or g_PlayerAssignments changes.

Closing the dialog, assembling the last user selection and choices, passing that to the parent page and opening a new dialog with the new data and the old settings seems like a workaround. The existing window should be updated instead of closed and reopened. (It could even be visible to the user if the renderer would render independently).

This way, the child GUI page could keep it's data localized, rather than "poisoning" the parent GUI page with information it ought to be agnostic of.

A third example could be the session dialogs (for example diplomacy dialog). They are currently implemented as a GUIObject rather than a GUIPage (this pattern is not possible for every dialog, as for example the network dialog should be openable from multiple pages).

var g_ChildPage = Engine.PushGuiPage(oldData);
g_ChildPage.updateSomething(newData);

[elexis]

Preliminaries:

• deleting obsolete JSI GUI stuff ​Phab:D1699
• fixing a memory leak ​Phab:D1700
• removing the m_CurrentGUI workaround ​Phab:D1701
• Discussion about JSInterface OOP use cases: ​https://wildfiregames.com/forum/index.php?/topic/17289-discussion-spidermonkey-upgrade/&page=9&tab=comments#comment-366063

Took a solid week to remove this JS workaround, but I think the code is much cleaner and extensible afterwards.

[wraitii]

In 22200:

Remove workaround in GetGUIObjectByName

rP7214 added a problem: Engine.GetGuiObjectByName is unaware of the caller GUI page.
So GUI pages in the background that still run the onTick and other event code tried to look on the topmost GUI page, rather than their own GUI page.
rP7769 added a workaround that has to be copied to any place that can call JS code.
If developers don't know about the reason for this workaround and add a new place that can call JS code (#5369), they won't be able to implement anything.

This removes this workaround by passing the pointer to the correct GUI page as callback data.

Patch By: elexis

Reviewed By: wraitii

Refs #5369

Trac Tickets: #5369

Differential Revision: ​https://code.wildfiregames.com/D1701

[elexis]

In 22530:

Delete unused broken JSI_IGUIObject::construct.

The constructor is invalid, because one cannot create or obtain and pass an IGUIObject C++ class instance pointer via JS, only triggering a crash when doing something with it.
If there was a use case, the GUIObject should be created with a GUIObject type specific constructor.
Remove obsolete getProperty comments.

From D1699, refs #5369 and wraitiis equivalent:
Differential Revision: ​https://code.wildfiregames.com/D1933

[elexis]

In r22588:
Move CGUIManager::LoadPage to CGUIManager::SGUIPage::LoadPage, because it only operates only on that struct.
Refs ​Phab:D1684 (patch also made an appearance in ​Phab:D2108)