TAStudio: allow persistent frame-bound RAM pokes

See also: #4570

If RAM-poked frames had a different color, it would be useful to have an explicit way to add persistent frame-bound RAM pokes. The idea is that each frame has an associated RAM poke changes table with a list of addresses and their values, and these get applied each time that range of frames is played back in TAStudio. For RAM freezes, the frame could perhaps instead be stored as an interval of frames (though this doesn't really play nicely once you start throwing branches into the mix).

Benefits: it allows RAM pokes to be more explicitly managed, instead of having to re-create or carefully remember them each time you want to experiment with nearby frames.

Downsides: this feature probably adds a lot of complexity for one somewhat niche situation, and the UI would need some care to clearly communicate what's going on.

Maybe this sort of thing is better demo'd as an external tool before/instead of incorporating into BizHawk itself.

One useful conceptual model for both users and for the design generally suggested on Discord is treating RAM pokes similar to inputs: this preserves useful intuition for the user, and also informs the implementation. They could actually be rendered in their own column on the input log itself. I envision something akin to markers, with an additional number corresponding to the number of RAM pokes.

One vital caveat: if memory pokes/cheats become allowed movie "inputs", the movie must clearly communicate it's cheated when it loads.

Start by reviewing TAStudio's existing RAM-poke behavior, input-log model, and movie-loading path; the issue names no files or tests. A complete design would need persistent frame-bound poke management, clear UI communication, branch behavior, and an indication that movies containing memory pokes are cheated.