Recording Controller / Auto-Playing Controller PR

[trickarcher]

This PR adds the ability to record and play automatic inputs. Still a work in progress.

[venkat24]

Let's try to rethink this approach. Our requirements are two modes:

1. Record all events that are passed to the controller, as a user presses them.
Now, we see that all the data required to complete this feature are present within the controller module. All we need to do is store them in memory. Now, while recording, there is nothing different going on in the controller, apart from the fact that it is recording all the button presses.

Now, why does controller need to peek into debugger's ticks? The point of the tick is that is synchronized across all objects. Every time Debugger::tick() is called, it will call Gameboy::tick() exactly once, which can call Controller::tick() exactly once. At any point in time, the controller does not need someone to tell it what the current tick count is, if it is maintaining it's own version of tick and incrementing it every time its parent (Gameboy) ticks.

We come to the Recording feature. Since our RecordingController should really just be a fancy Controller that implements IController. Hence, we can simply make RecordingController inherit from Controller, and override the methods like press_button and release_button. These overrides will record the input, and then call the base class method (Remember to mark such methods as virtual). From the perspective of a class that is using an IController, like Memory or Video, the interface stays totally the same, but the underlying instance is now actually a RecordingController.

2. Playback events existing in memory, just as a user would.
For the second part, we need to mock the user button presses, which means that something (apart from the video module) must make calls to press_button and release_button on the controller object. I think it makes sense to make this a part of the debugger, and perhaps have the user write a command that specifies the button inputs file to use. Then, the debugger makes these 'fake' calls to the controller module. We don't really require an AutoController here (unless it could be some helper of debugger core).

Apologies for that exceedingly verbose comment 😅, but I felt we could use some streamlining here. Let me know if you've got some opinions, and we can refine this a bit more.

[venkat24]

@anish0x2a Looks like the CI is failing now because it can't find the JSON header.

Can you fix this?

[venkat24]

This can be made protected instead of public

[venkat24]

rom_path is not a debug option, it needs to be passed regardless of Debugging.

Move this back out as a normal parameter.

[venkat24]

Add docstring comments for struct members.

[venkat24]

Like I mentioned above, the rom_path should still be an independent parameter.