Add boot-to-menu functionality

[NobodyNada]

Add an option to boot directly to the InfoHUD menu instead of the normal title sequence. This reduces the time from power-on to practice menu to about half a second:

https://github.com/tewtal/sm_practice_hack/assets/19418817/e5dc63f2-203f-434c-a637-3a5c8b82d9b7

A large portion of the boot time is spent uploading the sound engine to the SPC. To eliminate this delay, we load the SPC engine asynchronously in the background while the user is browsing the menu. (Don't worry, if the user exits the menu before the SPC finishes loading, we wait for it to finish first.)

The functionality is currently disabled by default, but can be enabled in the cutscenes menu. (Although enabling it by default might be something to consider as it would be convenient for TASing.)

Since this increases the likelihood of users selecting presets before selecting a save file, I've also made a tweak to @InsaneFirebat's work in https://github.com/tewtal/sm_practice_hack/commit/983e80845b80185e2587b3b04bc37e6dd7a2218a. Instead of detecting blank controller bindings and setting default bindings, we load the last used saved file after booting, or a default save file if none exists. That way we'll use the user's saved controller bindings and settings instead of the default. This applies both to boot-to-menu and the standard boot sequence.

[idlechild]

I was thinking, perhaps the development build could default to skip nintendo splash screen and go straight to menu.

I think the regular releases should stay as they are, but making the development build default to the faster boot up makes sense.

[NobodyNada]

Great thinking! I've implemented that.

I didn't make a new SRAM version for it, so it will only apply when booting from fresh SRAM. This solve what seems (to me) to be the most common use case for that feature: booting a dev build in an emulator environment that doesn't preserve SRAM (anyone else can just enable it manually.)

I also pushed a commit that removes the old fast splash option, as this seems to take care of most of the reason you'd want that. This lets us reuse the SRAM bit for that option, which means that people upgrading from older versions will automatically have quickboot enabled if they had the fast splash option before. If this is undesirable it can easily be reverted.

[InsaneFirebat]

It gets stuck in a loop if you soft-reset and then try to exit the menu. Never makes it past the first branch in cm_spc_init. In this case, the SPC didn't need to be initialized.

1. Progress through a fast-boot until the intro cutscene starts
2. Press L+R+Start+Select
3. Press B or Select to exit the menu (Start exits successfully?)
4. Infinite loop, testing in Mesen-S

[NobodyNada]

Great catch. I've pushed a fix to only initialize the SPC after a hard reset.

[NobodyNada]

Ah, I didn't realize we were trying to clean those up. I normally avoid them, but I used them here since I thought they made the common idiom of "increment + check for overflow" easier to read than with an explicit label.

I can replace them with explicit labels (or perhaps a macro) if desired.

[InsaneFirebat]

Not really a blocker imo, but the menu is triggered when pressing B at the file select menu.

[NobodyNada]

Ha, apparently pressing B on the file select menu triggers a soft reset: https://patrickjohnston.org/bank/81#f94D5

I'm inclined to leave it as-is, because it's simpler than changing the code to do something other than a soft reset (though changing the game state to zero would probably do the job.)

[InsaneFirebat]

Ha, apparently pressing B on the file select menu triggers a soft reset: https://patrickjohnston.org/bank/81#f94D5

lol I'd say keep it then

[InsaneFirebat]

Merged with #202