[runtimes] Thread-safe Sequence

[badlogic]

Problem

Sequences currently cause thread-safety issues when multiple skeletons share the same SkeletonData. When Sequence.apply(slot, attachment) is called during rendering, it mutates the shared attachment's state by calling attachment.setRegion(region) and attachment.updateRegion(). This modifies UVs and offset arrays on the attachment object itself. Since attachments are part of SkeletonData and shared across skeleton instances, concurrent rendering on multiple threads causes race conditions where one skeleton's rendering corrupts another's.

Solution

Introduce a new immutable type AttachmentTexture that holds texture region, UVs, and offset data. Sequences precompute an array of AttachmentTexture instances (one per sequence frame) at load time. During rendering, computeWorldVertices() and renderers select the appropriate AttachmentTexture based on the sequenceIndex stored in SlotPose. This eliminates mutation of shared state entirely.

Implementation details:

• Precompute all AttachmentTexture instances at sequence load time (ahead-of-time approach for C++/Swift compatibility)
• Runtimes with GC (Java, TypeScript, etc.) may optionally implement lazy caching
• No locks required - pure immutable lookups
• Memory impact minimal (mesh sequences are uncommon, typically 10-20 frames when used)

Runtimes

• Java
• C#
• C
• C++
• Haxe
• Typescript
• Swift
• Dart