Fix framebuffer when loading states/branches with OpenGL-supporting cores

[SuuperW]

We used to load the framebuffer of savestates that had screenshots (including TAStudio branches) by copying (and potentially resizing) the image into the core's framebuffer. This does not work with the newer way for cores to provide video output (via OpenGL textures). This resulted in users seeing incorrect images after loading savestates on those cores.

This has been solved by creating a new, temporary IVideoProvider when loading states and using that instead of the core's IVideoProvider until the next frame advance.

Let me know if there are any potential issues with doing things this way. In particular, MainForm's new LoadStateCommon method does more things than TAStudio's branch loading did. I am not sure, but they seems like things that should happen. My Lua script that I regularly use appears to work correctly with this update, but I imagine there could be others that rely on the old behavior.

Check if completed:

• I have run any relevant test suites
• I, the commit author, have read the licensing terms for contributors (last updated 2024-06-22) and am compliant

[SuuperW]

Any issues with merging this? @CasualPokePlayer you've been requested as reviewer.

[CasualPokePlayer]

My original plan to fix this is to rather simply have the OpenGL texture be updated on state load. Even then, a more proper fix is to just have new API for setting the video buffer properly. Doing what's done here doesn't look correct here (mainly as there's a ton more changes than just doing a "fix" for the framebuffer, what's with the DiscardApiHawkSurfaces call changes? You're also calling CallLoadStateEvent potentially with a null userFriendlyStateName, not to mention doing a lot more things here. Also, how does this interact with screenshots/video dumping? Does that still work or end up breaking?)

[SuuperW]

what's with the DiscardApiHawkSurfaces call changes?

There are no changes, in terms of behavior. That was being called from TAStudio when loading a state with no framebuffer, and it still is being called in exactly those situations.

You're also calling CallLoadStateEvent potentially with a null userFriendlyStateName

So I am. That is an oversight by me and I will fix it.

doing a lot more things here

Such as? I realize there are behavior changes aside from just the bug fix, but as I said in the PR post "they seems like things that should happen". (Calling SetMainformMovieInfo can't hurt anything, but might be redundant. Running all the tool updates and state load events instead of just the ones TAStudio had it its own update method is also a bug fix, which you can observe with event.onloadstate(function() print("loaded a state") end) not showing load events in TAStudio in current master. InputManager.AutoFireController.ClearStarts I am not entirely sure of since I never use AutoFireController. Maybe it doesn't make sense when TAStudio is open, I don't know.)

how does this interact with screenshots/video dumping?

They both work correctly, and I did test them both. There is no special code that needs to be written for them since they use _currentVideoProvider same as the main display.