Fixes #4050. Rename Command.Select and Selecting to Activate/Activating (#4470)

* Initial plan

* Rename Command.Select to Command.Activate and Selecting to Activating

Co-authored-by: tig <585482+tig@users.noreply.github.com>

* Add Activating event propagation to SuperView

Co-authored-by: tig <585482+tig@users.noreply.github.com>

* Update all comments and docs referencing Select to Activate

Co-authored-by: tig <585482+tig@users.noreply.github.com>

* Fix event log messages in examples to use Activating/Activate

Co-authored-by: tig <585482+tig@users.noreply.github.com>

* Revert automatic Activating event propagation that broke tests

Co-authored-by: tig <585482+tig@users.noreply.github.com>

* Update docfx documentation to use Activate/Activating terminology

Co-authored-by: tig <585482+tig@users.noreply.github.com>

* renames

* Revert "Add Activating event propagation to SuperView"

This reverts commit 6d82bee9ad.

* added command diagrams

* mermaid

* updated level 3

* again

* Select->Activate in MouseTests.cs

* Update Terminal.Gui/Views/Selectors/FlagSelector.cs

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

* Refactor: Rename Selecting to Activating in View APIs

Renamed the `Selecting` event and `OnSelecting` method to
`Activating` and `OnActivating` to better reflect their purpose.
Updated all related comments, test method names, variables,
and assertions in `View` and `ViewCommandTests` to align with
the new terminology.

Improved code clarity by using `_` for unused parameters in
lambda expressions. Renamed properties like `HandleSelecting`
to `HandleActivating` and adjusted naming conventions for
consistency (e.g., `OnactivatingCount` to `OnActivatingCount`).

These changes enhance readability, maintainability, and
terminology consistency across the codebase.

* Update Terminal.Gui/Views/Selectors/OptionSelector.cs

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

* Typos

---------

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: tig <585482+tig@users.noreply.github.com>
Co-authored-by: Tig <tig@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

docfx/docs/command-diagrams.md

@@ -0,0 +1,101 @@
+### Level 1: Basic View Command Flow
+
+This diagram shows the fundamental command invocation flow within a single view, demonstrating the Cancellable Work Pattern with pre-events (e.g., `Activating`, `Accepting`) and the command handler execution.
+
+```mermaid
+flowchart TD
+    input["User input (key/mouse)"] --> invoke["View.InvokeCommand(command)"]
+    invoke --> |Command.Activate| act_pre["OnActivating + Activating handlers"]
+    invoke --> |Command.Accept| acc_pre["OnAccepting + Accepting handlers"]
+
+    act_pre --> |canceled| act_stop["Stop"]
+    act_pre --> |not canceled| act_handler["Execute command handler"]
+    act_handler --> act_done["Complete (returns bool?)"]
+
+    acc_pre --> |canceled| acc_stop["Stop"]
+    acc_pre --> |not canceled| acc_handler["Execute command handler"]
+    acc_handler --> acc_prop["Propagate to default button/superview if unhandled"]
+    acc_prop --> acc_done["Complete (returns bool?)"]
+```
+
+**Key Points:**
+- Commands follow the Cancellable Work Pattern: pre-event → virtual method → event → handler
+- `OnActivating`/`OnAccepting` or event handlers can cancel via `args.Cancel = true`
+- Command handlers return `bool?`: `null` (no handler), `false` (executed but unhandled), `true` (handled/canceled)
+- `Command.Activate` is handled locally (no propagation)
+- `Command.Accept` may propagate (see Level 2)
+
+### Level 2: Accept Propagation with Button.IsDefault
+
+This diagram shows how `Command.Accept` propagates through the view hierarchy, including the special case where a default button intercepts the command even when invoked from another view.
+
+```mermaid
+flowchart TD
+    input2["User input (Enter)"] --> tf_accept["TextField.InvokeCommand(Accept)"]
+    tf_accept --> tf_pre["TextField OnAccepting + Accepting"]
+    tf_pre --> |canceled| tf_stop["Stop"]
+    tf_pre --> |not canceled| tf_default_check["Find sibling IsDefault button"]
+
+    tf_default_check --> |found| call_default["Invoke default Button.Accept"]
+    call_default --> btn_pre["Button OnAccepting + Accepting"]
+    btn_pre --> btn_done["Handled → return true"]
+    btn_done --> tf_result1["Handled by default button"]
+
+    tf_default_check --> |not found/returned null| call_super["Propagate to SuperView (Dialog)"]
+    call_super --> dlg_pre["Dialog OnAccepting + Accepting"]
+    dlg_pre --> dlg_done["Handled/propagated result"]
+```
+
+**Key Points:**
+- `Command.Accept` checks for a sibling `Button` with `IsDefault = true` in the `SuperView`
+- If found and not the source view, the default button handles the command first
+- If unhandled or no default button, command propagates to `SuperView`
+- `SuperView` (e.g., `Dialog`) can handle accept to close or trigger actions
+- This enables Enter key to activate default buttons from any focused view
+
+### Level 3: Complete Flow with Shortcut, MenuBar, and Menu
+
+This diagram illustrates the complete command flow in a complex hierarchical scenario involving `Shortcut`, `MenuBar`, `Menu`, and `MenuItem`, showing how commands route through multiple views and how `Accepted` events propagate back up the hierarchy.
+
+```mermaid
+flowchart TD
+    sc_header["=== Scenario 1: Shortcut Activation (Alt+F) ==="]
+    sc_header --> sc_input["Alt+F pressed"]
+    sc_input --> sc_find["Shortcut finds MenuBarItem"]
+    sc_find --> sc_hotkey["MenuBarItem.InvokeCommand(HotKey)"]
+    sc_hotkey --> sc_pre["OnHandlingHotKey + HandlingHotKey"]
+    sc_pre --> sc_focus["MenuBarItem sets focus"]
+    sc_focus --> sc_show["MenuBar shows popover for MenuBarItem"]
+    
+    sc_show --> nav_header["=== Scenario 2: Menu Navigation (Arrow Keys) ==="]
+    nav_header --> nav_input["Arrow keys pressed"]
+    nav_input --> nav_activate["MenuItem.InvokeCommand(Activate)"]
+    nav_activate --> nav_pre["MenuItem OnActivating + Activating"]
+    nav_pre --> |canceled| nav_stop["Stop"]
+    nav_pre --> |not canceled| nav_focus["MenuItem sets focus"]
+    nav_focus --> nav_changed["Menu.SelectedMenuItemChanged raised"]
+    nav_changed --> nav_bar["MenuBar.OnSelectedMenuItemChanged"]
+    nav_bar --> nav_done["Update popover visibility if needed"]
+    
+    nav_done --> acc_header["=== Scenario 3: Accept Menu Item (Enter) ==="]
+    acc_header --> acc_input["Enter pressed on MenuItem"]
+    acc_input --> acc_pre["MenuItem OnAccepting + Accepting"]
+    acc_pre --> |canceled| acc_stop["Stop"]
+    acc_pre --> |has action| acc_exec["Execute menu item action"]
+    acc_exec --> acc_accepted["MenuItem.RaiseAccepted"]
+    acc_accepted --> acc_menu["Menu.OnAccepted propagates"]
+    acc_menu --> acc_bar["MenuBar.OnAccepted"]
+    acc_bar --> acc_close["MenuBar hides popover, deactivates"]
+    
+    acc_pre --> |has submenu| acc_sub["Propagate to parent Menu.Accept"]
+    acc_sub --> acc_popover["Show submenu popover"]
+    acc_popover --> acc_submenu_done["Submenu displayed"]
+```
+
+**Key Points:**
+- **Scenario 1 (HotKey)**: Shortcut activates menu bar item via `Command.HotKey`, which sets focus and triggers MenuBar to show the popover
+- **Scenario 2 (Activate)**: Arrow keys navigate menu items via `Command.Activate`, which is handled locally but raises `SelectedMenuItemChanged` for MenuBar coordination
+- **Scenario 3 (Accept)**: Enter key executes menu items via `Command.Accept`, followed by `Accepted` event propagating up (MenuItem → Menu → MenuBar) to close menus
+- `Command.Activate` doesn't propagate but uses view-specific event (`SelectedMenuItemChanged`) for hierarchical coordination
+- `Accepted` is a post-event (not part of Cancellable Work Pattern pre-event phase) that signals action completion
+- MenuBar uses `SelectedMenuItemChanged` to manage popover visibility, demonstrating current workaround for lack of generic `Activate` propagation