Improve handling of info subcommands and fix support for `info stack`

[jansorg]

This PR improves the info command and handling of its subcommands.

• 1ae1b53c9eb2cabcf8c05b4c452fadca1b01ba86: sync handling of info subcommands with bashdb. Instead of maintaining two lists of subcommands (which were out of sync again), the code now relies on the array _Dbg_debugger_info_commands, which is populated when the info subcommand files are sourced. The code also takes care of the command abbreviations (as in bashdb), so that info sta is treated as info stack. The code was copied from bashdb and adjusted for Zsh. Before this change the invocation of info called all subcommands, which is unexpected (and was probably added for debugging, I think).
• The last two commits move the code of info stack into a subcommand file and remove the limitation to only one stack frame. I'm not sure why anyone would like to only see the top frame of the stack. It seems to be very old code, so I changed it to work in the same way as bashdb. See below for an before/after comparison.

The original code passed a $label arg to the sub command, it was set to typeset label=$2 and the sub commands were then invoked with ${_Dbg_debugger_info_commands[$info_cmd]} $label "$@". If I understand the code correctly, then this turned info variables integer into ${_Dbg_debugger_info_commands["variables"]} "integer" "variables" "integer". With this PR info sub commands are invoked without the name of the subcommand. Several sub command source files were adjusted to use the new argument values.

To Do:

• [ ] I haven't added tests yet. I'll also have to wait for this PRs CI to see if tests are failing.

info stack before this PR:

zshdb<2> info stack
->0 in file `/home/jansorg/test.zsh' at line 4

info stack with this PR:

zshdb<2> info stack
->0 in file `/home/jansorg/test.zsh' at line 4
##1 inner called from file `/home/jansorg/test.zsh' at line 8
##2 outer called from file `/home/jansorg/test.zsh' at line 11
##3 /home/jansorg/test.zsh called from file `./zshdb' at line 141

[rocky]

@jansorg I am okay with merging this as is and doing the todo as another PR or waiting for everything to be done and then merging. Your choice.

As for things being out of sync, yes, that has been a persistent problem. There could have been one repository with different branches that don't get merged which is what I do in some other projects. Given though the history of this where one started on sourceforge in SVN before git was around, things ended up this way.

With branches there is always the problem of an inadvertent merge.

I may have said this before, but if you want to be able to commit directly to this repository let me know.

[jansorg]

If possible, I'd like this to be merged. There are a few open pull requests now and merging them would help to work on follow-up changes. If you don't mind, write-access would be great -- I'll be careful with my commits :)

[rocky]

You should have an invitation to join the repository now.