Support context filtering for commandMenu parent items in custom commands

[rcdailey]

Is your feature request related to a problem? Please describe.

Currently, when using commandMenu in custom commands, the parent menu item always appears globally across all panels. The context field only applies to individual child commands within the menu, which means the menu is filtered at runtime - child commands that don't match the current context are hidden from the menu.

This creates a suboptimal UX when you want a submenu that's only relevant to a specific panel. For example, I want a merge operations submenu (SHIFT+M) in the commits panel to merge a selected commit into the current branch, but I don't want this menu appearing in other panels like files or status.

Describe the solution you'd like

Allow the context field on commandMenu parent items to control which panels display the menu keybinding, similar to how regular custom commands work.

customCommands:
- key: M
  context: commits,subCommits  # Menu only visible in commits panels
  description: Merge operations
  commandMenu:
  - key: m
    command: git merge --no-ff {{.SelectedCommit.Hash}}
    description: Merge commit (--no-ff)

This would make the SHIFT+M keybinding only register in the specified contexts.

Describe alternatives you've considered

1. Current workaround: Accept the global menu and rely on runtime filtering - the menu appears everywhere but shows "No applicable commands in this context" when opened in wrong panels
2. Separate keybindings: Skip the submenu and use individual keys for each operation - loses the organizational benefit of menus
3. Override built-in keybindings: Use keybinding overrides to add functionality to existing context-specific menus - only works if a suitable built-in menu exists

Additional context

Looking at pkg/gui/services/custom_commands/client.go:35, commandMenu parents are hardcoded with ViewName: "" (global binding). The context filtering happens inside showCustomCommandsMenu() at lines ~58-65 by checking the current view at runtime.

I'm interested in implementing this feature if the maintainers are open to it. The change would involve:

1. Allowing context field on commandMenu parent items during validation
2. Using the context to set appropriate ViewName in the binding instead of empty string
3. Maintaining backward compatibility by defaulting to global when context is omitted