Fix Animate generated class inclusion and duplicate runtime resolution

[Tutez64]

Summary

This PR fixes two separate Animate-related issues.

1. Generated Animate linkage classes were not being reliably included in the Haxe build when generate="true" was enabled on libraries. In practice, this meant some symbols that should have been instantiated as their exported class fell back to generic MovieClip instances on C++/OpenFL. For the game case that motivated this work, nested collision symbols such as NavCollisionRectangle then became impossible to identify and remove by class name, which caused the visible red collision overlays. The first part of this PR fixes the tooling side so that generate="true" works correctly for the selected libraries.

2. Once generated classes are enabled across multiple libraries, duplicate exported class names can resolve to the wrong library at runtime. Generated classes were effectively tied to a specific UUID + symbolID, so another library exporting the same class name could instantiate the wrong symbol. The second part of this PR fixes that runtime resolution so generated classes are bound to the library that is actually instantiating them.

Changes

• fix the Animate tooling path in Tools.hx so generated classes are actually added to the Haxe build and restored from cache correctly
• make Animate generated MovieClip classes resolve against the runtime library being instantiated, instead of a fixed library/symbol pair
• apply the same runtime-resolution strategy to generated SimpleButton classes
• keep BitmapData aligned with the same strategy for consistency/future-proofing

Repro

SWFAnimateCollisionRepro.zip

A minimal repro project is included to demonstrate:

• the original visible collision-overlay issue when generation is disabled
• wrong duplicate-linkage resolution for shared MovieClip and SimpleButton exports when the runtime-library fix is removed
• a separate unresolved issue where enabling generation on certain UI assets can emit classes extending fl.controls.ScrollBar, which does not exist on Haxe/OpenFL. This PR does not fix that issue, it is included only to document it in case someone wants to investigate it separately.

Note

This PR depends on #40.

[joshtynjala]

a separate unresolved issue where enabling generation on certain UI assets can emit classes extending fl.controls.ScrollBar, which does not exist on Haxe/OpenFL. This PR does not fix that issue, it is included only to document it in case someone wants to investigate it separately.

fl.controls.ScrollBar is an ActionScript 3.0 class included with Adobe Animate (and Flash Pro before that). It is not built into Flash Player or AIR. Even though the AS3 code is included with Animate, it is not released under an open source license. Anyone with an Animate license should be able to port the original AS3 code to Haxe, if they need it. However, they would not be able to legally share that code with anyone who does not also have their own Animate license.

Someone could probably write a custom implementation using the same API and all new code. If they do, that should be a separate library from the OpenFL, Lime, and SWF libraries.