Implement REPORT_ASSOCIATED_TEXT for macOS option as alt

[peterjc]

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

Quoting https://github.com/crossterm-rs/crossterm/blob/0.28/src/event.rs#L306

        // *Note*: this is not yet supported by crossterm.
        // const REPORT_ASSOCIATED_TEXT = 0b0001_0000;

Quoting https://github.com/crossterm-rs/crossterm/blob/0.28/src/event/sys/unix/parse.rs#L283

    // *Note*: this is not yet supported by crossterm.
    // if bits & 16 != 0 {
    //     flags |= KeyboardEnhancementFlags::REPORT_ASSOCIATED_TEXT;
    // }

Describe the solution you'd like

Apple keyboards have a "option" key in place of the "Alt" key on IBM/Windows style keyboards, Apple maps "Alt" to "option" when using such external keyboards. Naturally on terminal editors, it is sometimes expected that on macOS the "option" key will behave like "alt" on Windows/Linux.

Currently most terminals on macOS offer a boolean setting controlling how the option key behaves, like Kitty's macos_option_as_alt, which gives just one mode or the other.

For example, on my layout option+3 gives "£", while option+o gives "ø". I personally use "£" quite often but don't need option+3 (aka alt+3) in my terminal. On the other hand, I rarely use "ø" but would like to map Alt+o as a shortcut for open file.

My understanding of the discussion on helix-editor/helix#7478 is if REPORT_ASSOCIATED_TEXT was implemented, on macOS the Helix editor could detect both that the user pressed option/alt and some key, and receive the often accented character that gives on macOS. This would allow context dependent interpretation.

[peterjc]

Cross reference #754 which was a step in this direction, defining REPORT_ALTERNATE_KEYS.