avm2: Use actual ShowFrame tag count instead of header for most things

[Aaron1011]

Some SWFS have 2 frames, but only declare 1 frames in the SWF header. This PR allows those swfs to advance to the next frame (either normally or via a goto).

[Lord-McSweeney]

Does this mean we have to decode all the SWF tags twice now?

[Aaron1011]

Yes, but the actual decoding work here is just repeatedly reading tag codes and lengths. Also, it's only done for root clips.

[Lord-McSweeney]

Does this mean gotos in AVM1 that go past the frames in the header are clamped? I made a small test and AVM1 also seems to ignore the header frame count in FP.

[torokati44]

Possibly distantly related: #6144 and #2705.

[adrian17]

Just for completeness, as researched on Discord, this doesn't feel correct; as in: in FP, I can observe that the playhead doesn't stop at the last ShowFrame, but instead it actually processes tags until the last one, and only then it either loops or stops (but it doesn't treat it as a real "frame"). Ways to observe it:

• with DoABC2 and looping (the tag runs, the script initializer runs; I assume that the "script initializer queue" is executed after the loop reaches the first ShowFrame, because the script does not visibly run with a manual gotoAndStop(), just with a loop)
• with a control tag like RemoveObject2 past the last ShowFrame. The requested DO actually gets destroyed, even if after calling .gotoAndStop(), the .currentFrame looks as-if the playhead stopped on the last "real" ShowFrame. (I don't know whether the "playhead pointer" actually stopped at the EOF, or rolled back to the last "real frame". Might be possible to somehow observe it by repeatedly calling .gotoAndStop(past_the_end) and looking for some observable side effects)
• I wasn't able to observe this with PlaceObject; maybe it's possible with a more complex test, but I don't really know yet :( Maybe it just figures out that the DO is to die anyway and doesn't actually instantiate it; or all the DO AVM2 constructors are delayed until ShowFrame (which doesn't exist here)... needs futher research

Also, intuitively, the count-in-advance logic would interact badly with possible async download implementation. The way FP works does make sense if you think of the playhead as not knowing anything about the bytestream in advance and just parsing tags until either a ShowFrame or EOF.
(and just personally, I'm not a fan of parsing tags twice ;) )