I don't know current hacking grade SNES emulators that well but on the NES in things like FCEUX there are function finders wherein you go to the game, do essentially everything* but load the menu (move up, down, left, right, interact, wait to see if it changes audio, wait for any npcs to move...), tell it then to watch and when you next load a menu it will say "haha this function/list of functions was never called before" and then you have your menu handler.
*if you want to go to a really low feature area of the game (no npcs, nothing to interact with) then that also works. Doing "everything but" is just a way to narrow down the eventual search list.
That said the traditional way would be to look at the button press handler (the buttons are some register in the hardware somewhere, sometimes they will be copied (debounced) to another normal area of memory, usually then every vblank will be a function that checks this and responds accordingly) and see what it does.
Menu hacking itself is something of an aside from most of the rest of text hacking. It is where you encounter things like fixed width sections (no pointers or size values, see also why various RPGs of that era will have odd spell names), issues with graphics (most games will have a next text box command, or you can finesse your translation to fit within limits, menus however, especially overlay ones, tend not to have such luxuries and that could lead you down a massive hole), direct functionality tied to it (meaning it won't necessarily be in nice text sections and may even be wedged in the game code somewhere), it might even have a different font and encoding but that is probably not a huge deal here.
If there are sub menus (think the sort of thing a bad UI might make you press b 20 times to get back to the game) then that can be both easier or harder to handle.
Basically there is no general case for the second bullet point so I doubt you will find anything of great general relevance, and actually probably not much in the game specific world either. Anybody playing at adding menus like this probably knows anything I will write here in this reply.
Option 2. If there is a menu option you don't care about or could be considered redundant then knock that out in favour of your debug menu. It may save fiddling with graphics issues as well.
A lesser, but more elegant in some ways, version of this would be to do like the game devs of that era often did and "hide" the debug menu call in a lesser used menu function. You find it in the same way as the general menu call function (maybe even easier if you do have a feature like the function finder as there are even fewer things to do in a menu)