Fix UIScreen reference issues causing garbage collection problems.

[andrewgu]

There's probably a memory leak related to using UIScreenListeners without specifying a default class. Would be generally better to be able to register handlers without needing to go through the hacky interface.

[andrewgu]

More details: it looks like keeping a reference to the screen that's being listened to (MCM_OptionsScreen) is a problem in general, and it may be causing the glitches. Need to investigate potential workarounds. Maybe make divorce the MCM_API and MCM_API_Instance from the MCM_OptionsScreen implementation through callbacks?

[andrewgu]

Figured out a solution: split the UIScreenListener into two parts and put the MCM specific code in a closure that the UIScreenListener creates transiently.

Will add this to the documentation. Example can be seen in MCM_TestHarnessListener.uc.

[andrewgu]

TODO:

1. Update documentation
2. Notify mod authors about the object wrapping fix demonstrated in the test code.

[BTernaryTau]

I got around this issue by simply deleting any references to objects that need to be garbage collected in the save and cancel button handlers. However, this requires every method of exiting the options screen to trigger one of those handlers, so I wanted to have you confirm if that is true or not.

[andrewgu]

@BTernaryTau Yes, that will work as long as you got rid of all of the references before any Unreal engine scene transition happens. Doing it on a confirm/cancel button handler will work, though if I had to recommend an approach to both people trying to use MCM for the first time and people trying to retrofit their MCM code, I would recommend the example I put into MCM_TestHarnessListener.uc.

In that example, rather than explicitly setting references to None in the screen listener, just put all of the UI code into a throwaway object so that the screen listener can avoid storing references altogether. The throwaway object gets cleaned up later alongside all of the UI code.