Remove _layerOrder and just store sprites in-order

[adroitwhiz]

Depends on #207.

This gets rid of the clones hierarchy and _layerOrder property, and stores every rendered target (sprite, stage, or clone) in one array kept in layer order. Clones now refer directly to the "original" sprite instead of their parent.

While this does require some more management of that array, it means we don't have to:

• Maintain the _layerOrder property
• Construct and sort a bunch of new arrays every time we want to loop through all the rendered targets (slow)
• Traverse upwards through the clone hierarchy to find the "original" sprite

Starting triggers is also done in top-down order now (reverse layer order), which matches how Scratch does it.

[PullJosh]

Nice! Glad to see compatibility improvements and simpler code.

I've been meeting with some of the good folks working on Patch, a "Python Scratch" that serves a similar purpose as Leopard but for Python rather than JavaScript. They are updating their codebase to use Leopard as their underlying VM rather than their forked version of scratch-vm. (scratch-vm was quite messy to integrate with and Leopard is much simpler.)

If they want to provide a "live" editor experience like Scratch, where sprites perpetually "exist" even when no scripts are running, and the instances appear on the stage immediately when creating or modifying sprites in the editor, it would be nice if they could add/remove sprites to/from a running project. We currently disallow that, mostly as a historical decision. As far as I recall, the reasoning for disallowing it was basically we don't know if the behavior will work correctly and nobody would ever want to do that anyway.

I'm wondering, now that you've just been digging into this code, if you have any sense of how difficult it would be to enable adding/deleting sprites (which are not necessarily clones) while a project is running.

[adroitwhiz]

I don't think it would be that difficult. In fact, this PR adds addSprite and removeSprite methods that could probably be used as-is.

EDIT: Although removeSprite doesn't currently handle removing all of a sprite's clones, as it is currently only used for removing individual clones themselves. That would probably not be too difficult to add, though.