References to Data Assets that inherit from Blueprints may be broken during reinstancing

It is possible to create new Data Asset instances in the editor that inherit from a blueprint-defined subclass of UDataAsset. This flow is not very well supported, and generally it is safer to just use the Blueprint CDO/Default objects as is. But, this flow is used in some licensee and blueprint-heavy games.

The engine reinstancing logic does not handle this well in all cases, especially with a complicated blueprint hierarchy. Based on licensee reports, it appears this can lead to issues during asset loading where the data assets point to invalid REINST classes. This happens if the blueprint parent class is first loaded and recompiled while the data asset itself is being loaded. Once that reinstance corruption has happened, it does not appear to get fixed up in the later reinstance pass. This can then cause data to be broken during cooking or other save operations.

The licensee-identified workaround is to have FLinker expose it's imports to the GC reference system so they will get fixed up during the reinstance pass, but this may conflict with other BP compile on load problems. 

Based on licensee UDN with no hard internal repro, but general steps:

1. Create a Blueprint subclass of of UDataAsset, and fill out an inheritance hierarchy below it
2. Create data asset instances of multiple subclasses in that hierarchy
3. Reference those data asset instances from something used in a cooked game
4. Cook game, reference may get nulled