Improved fix for preserving DP registers when opening/closing the menu

[idlechild]

I don't think we want to restore DP registers twice like we do for the timer variables. It is possible there is a specific DP register we should restore a second time but I'd like to know why rather than blanket restore. The timer variables are restored twice because we let a few frames execute before returning control to the user. We wanted the timer variables to be reasonable when running those few frames, but we also don't want to count those frames when computing room times later.

We definitely should restore DP registers later than I was doing in my earlier solution to group it with cgram, since after restoring cgram we were calling methods like initialize HUD that we would not call in the middle of a room normally. Whatever methods like that are doing with DP registers, we want to undo that to provide a more realistic memory state.

While doing this I also cleaned up some unnecessary PHP/PLP calls, where we were calling %ai16() later on anyway.

This does fix the issue I was having with $0026 and $0028 registers not being maintained. Planning to release this later today; let me know if you have concerns.

[idlechild]

Thanks InsaneFirebat for the feedback on the $2100 register. I had been using it incorrectly and over time I propagated this to other places so fixing those too. I don't think I introduced the ones using 8-bit X register but I did most of the others. Some of the fixes probably do nothing (might not be in a situation where it matters) but still better to stay consistent... except the vanilla debug routine. I kept that at regular $2100 since that's what vanilla does (tbf to Deer Force since the value is not a fixed 80 or 0F that one wouldn't have been easy to do correctly even if the SNES behavior was known).

[InsaneFirebat]

For reference on the $2100 behavior: https://undisbeliever.net/snesdev/registers/inidisp.html#writing-outside-vblank
Also some further reading linked at the bottom