Creating/Destroying UWorlds rapidly can cause dangling pointers from UAutoDestroySubsystem

To summarize what I'm seeing there, a bunch of UObjects relating to that world have been destroyed but not all destructed. The UAutoDestroySubsystem pointer is still on the static tickable list, and its Outer (the world) pointer is now hanging.

It seems that the outer of the AutoDestroySubsystem (UWorld) can end up being a garbage pointer when the subsystem is still in the Tickables list, but the world has been destroyed. 

The user mentioned this being an issue in their unit tests, where they create and destroy a lot of UWorld objects. 

We can probably fix this by updating the condition on when we tick via the FTickableGameObject interface. 

1. Create a new BP that starts a timer for 2 seconds, and sets bAutoDestroyWhenFinished to true
2. Create a new level that has a few of these BP's
3. Save this level (Level A)
4. Create a new level (Level B) that loads Level A on tick 500 times in the level BP
5. Run this, and observe that there is no crash

> GameClient-Win64-Debug.exe!UStruct::IsChildOf(const UStruct * SomeBase) Line 476 C++
GameClient-Win64-Debug.exe!UObjectBaseUtility::IsA<UWorld>() Line 504 C++
GameClient-Win64-Debug.exe!UWorldSubsystem::GetWorld() Line 14 C++
GameClient-Win64-Debug.exe!UAutoDestroySubsystem::Tick(float DeltaTime) Line 89 C++
GameClient-Win64-Debug.exe!FTickableGameObject::TickObjects(UWorld * World, int InTickType, bool bIsPaused, float DeltaSeconds) Line 151 C++
GameClient-Win64-Debug.exe!UGameEngine::Tick(float DeltaSeconds, bool bIdleMode) Line 1804 C++
GameClient-Win64-Debug.exe!FEngineLoop::Tick() Line 4871 C++
GameClient-Win64-Debug.exe!EngineTick() Line 63 C++
GameClient-Win64-Debug.exe!GuardedMain(const wchar_t * CmdLine) Line 172 C++
GameClient-Win64-Debug.exe!WinMain(HINSTANCE__ * hInInstance, HINSTANCE__ * hPrevInstance, char * __formal, int nCmdShow) Line 257 C++