this fixes the giant memory leak that happens due to not freeing custom level data when closing a lobby.
`DynOS_Lvl_ModShutdown` was not freeing the data nodes for the level data, it was only freeing the surface data.
To fix this, I have made it use `DynOS_Gfx_Free` to free the `GfxData` correctly. I found that the level script VM will still be trying to warp from the custom level after `DynOS_Lvl_ModShutdown` is executed, so I added a schedule to simply free it the next frame.
I've made it force the level script to change to a vanilla level during mod shutdown. This is critical to ensure the VM doesn't continue to read from a freed level script.
Removed the explicit deletion of data nodes in `DynOS_MovtexQC_ModShutdown` because `DynOS_Gfx_Free` already frees that, and it's actually data owned by the data node, so it's more appropriate in `DynOS_Gfx_Free`
When generating multiple actors, if two or more data nodes share the same name, the generated actors can reference the wrong nodes in their display lists/geo layouts.
This results in:
- The wrong nodes compiled into binary files
- Intermediate layouts generated as actors since nothing is referencing them anymore, treating them as root geo layouts
The simplest fix was to first check for the model identifier (renamed to `mDataIdentifier`, since it's no longer related to models) when looking for nodes, to ensure it picks the right node, even if multiple nodes share the same name.
