Asset Registry GetDerivedClassNames does not work properly during editor startup

This bug comes from https://udn.unrealengine.com/questions/585499/view.html which describes a problem where a licensee is trying to use the AssetManager to scan a primary asset type that is generated by a game or plugin-added blueprint subclass. This works correctly in the editor or a cooked game, but will fail in an editor executable run with -game or -cook. The reason why has to do with how the asset registry is initialized:

1. At editor startup UAssetRegistryImpl is created, which first calls CollectCodeGeneratorClasses. At this point in editor builds, only low level modules are loaded so it will probably only finds UBlueprint and other engine-defined BP classes. In cooked builds all modules are already loaded so it finds all of them
2. It then schedules another call to RefreshNativeClasses for PostEngineInit, which will find the rest of the generators like UAbilitySystemBlueprint and any game-specific ones
3. The asset manager then initializes and calls UAssetManager::ScanPrimaryAssetTypesFromConfig. In -game and cook builds it goes ahead and does all of the scanning now, which uses GetDerivedClassNames to validate that a found blueprint is the right class. In editor builds, it will schedule a second call of this to happen after the async asset registry scan finishes but in -game and cook it does a synchronous scan
4. PostEngineInit happens which calls CollectCodeGeneratorClasses, which in the editor finds the rest of the BP classes
5. The async asset registry scan finishes and calls ScanPrimaryAssetTypesFromConfig again, but only in proper editor mode

The summary is that things work fine in cooked game and normal editor modes, but in editor builds that are called with -game or a commandlet like cook, the asset registry's list of blueprint classes will be wrong. This breaks the asset manager scan as well as other code that might request the class hierachy of unloaded classes

This is difficult to verify as it comes from a UDN and none of our internal games have content that will activate it. Here are the theoretical steps that a programmer can verify:

1. Put code breakpoints in UAssetRegistryImpl::CollectCodeGeneratorClasses and UAssetManager::PostInitialAssetScan
2. Launch ActionRPG or another game using the default command line, you will get two calls to CollectCodeGeneratorClasses before PostInitialAssetScan, and the second call will increase the number of code generator classes
3. Launch game again, but with -game or a cook command line, if this is broken you will get only one call to CollectCodeGeneratorClasses before PostInitialAssetScan and the code generator classes will be missing plugin/game classes like GameplayAbilityBlueprint