Add keyboard shortcuts to rename tabs/windows and cycle tab color

[fabdelgado]

Renaming a tab/window and setting a tab color already existed but were buried in the View menu with no key equivalents, which makes organizing a window full of tabs (e.g. many concurrent agents) slow.

This wires up default shortcuts and adds a one-keystroke color cycle:

• Edit Tab Title: Ctrl-Cmd-R (reuses editTabTitle:)
• Edit Window Title: Ctrl-Opt-Cmd-R (reuses editWindowTitle:)
• Cycle Tab Color: Ctrl-Cmd-E (new cycleTabColor: action)

cycleTabColor: steps the current tab through the tabColorMenuOptions presets, then to no color, then wraps around. The shared "apply a color to every session in a tab" logic is hoisted into applyTabColor:toTab:, used by both the color menu and the new shortcut. Preset parsing is extracted to +[ColorsMenuItemView presetTabColors] so the menu and the cycle share one source of truth.

[gnachman]

Can't use control-command or control-opt-command for a shortcut because they are reserved for creating new windows/tabs. Commit e376ba3 adds a spreadsheet documenting the existing shortcuts.

Cycle tab color is worth keeping, though. Just revert the shortcut changes.

[fabdelgado]

Ready the changes!, thanks!

[gnachman]

Thanks for this! The functionality is nice, but I don't think the shortcut side is wired up the way the description implies.

The PR title/description say it "wires up default shortcuts" (Ctrl-Cmd-R / Ctrl-Opt-Cmd-R / Ctrl-Cmd-E), but as far as I can tell no shortcut is actually bound by any mechanism:

• The new Cycle Tab Color menu item in MainMenu.xib has an empty <modifierMask key="keyEquivalentModifierMask"/> and no keyEquivalent attribute, so it has no key equivalent.
• Edit Tab Title / Edit Window Title are untouched, so they still have no key equivalent either.

More importantly, this should really be a first-class key binding action rather than a menu key equivalent. iTerm2 lets users assign keys to actions in Preferences > Keys, and hardcoding default menu key equivalents tends to collide with users' existing bindings and can't be remapped easily. The right home for something like "Cycle Tab Color" is the KEY_ACTION_* system. Adding one means touching:

• sources/Keyboard/iTermKeyBindingAction.h (new KEY_ACTION_CYCLE_TAB_COLOR enum case)
• sources/Keyboard/iTermKeyBindingAction.m (the switch statements that classify/label the action)
• sources/PTYSession/PTYSession.m (dispatch to the handler)
• sources/Settings/iTermEditKeyActionWindowController.m (expose it in the picker)

KEY_ACTION_MOVE_TAB_LEFT / MOVE_TAB_RIGHT are a good template to follow across those files.

The Objective-C refactor itself looks good: hoisting applyTabColor:toTab:, extracting +[ColorsMenuItemView presetTabColors], and the cycle logic (colorspace-safe comparison, restart-at-preset-0 for unrecognized custom colors) all read cleanly.

Two smaller notes if you keep a menu item too:

• The description's rename shortcuts for tab/window titles aren't in the diff at all.
• If it stays a menu item without a default binding, the description should be updated so it doesn't promise shortcuts that aren't there.