Document the meanings of 'Memory.current' and 'Memory.previous'

[FramePerfection]

The values in Memory.current and Memory.previous are updated via Memory.update() and Memory.update_previous(), which are called at weird times. It is difficult to tell what exactly to expect what game state information those values will hold in the different mupen callbacks like atvi, atinput or atdrawd2d.

To combat this, the points in time that the game state that are supposed to be held by Memory.current and Memory.previous respectively should be well specified, and any offending code should be adjusted accordingly.

[Aurumaker72]

cc from discord:

atinput is called when the controller is read: that is before any game logic has run in sm64
that means that reading any memory in that callback will effectively get you the values from the last frame (aka the values from the beginning of a new frame prior to any gmae logic computation)
atvi is called at the very end of the game logic (sm64 presents after it has finished its logic) so the state is done and updated

because we dont want input lua to be delayed by one frame, we read memory in atvi
this is what is in Memory.current (generally, except for the dirty hacks)

[FramePerfection]

I just caught off guard by the fact that Memory.update_previous() is called in at_input (the atinput callback), which makes Memory.previous hold the same values as Memory.current for the scope of all processors.
I'm not sure if this is intended behavior (or if it'd break anything), or if the Memory.update_previous() call should be moved to at_vi (the atvi callback) like so:

local function at_vi()
    Memory.update_previous()
    Memory.update()
end