Support X1/X2 (back/forward) mouse buttons

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

MouseButton only has Left, Right, Middle (src/event.rs:820). There's no way to detect the X1/X2 (back/forward) mouse buttons that many mice have.

On Unix, this isn't just a missing feature — SGR mouse sequences for X1/X2 currently produce a parse error instead of being ignored or decoded. In parse_cb (src/event/sys/unix/parse.rs:777):

let button_number = (cb & 0b0000_0011) | ((cb & 0b1100_0000) >> 4);

This already computes button_number up to 8/9 for X1/X2 (per the xterm SGR mouse protocol), but the match arm only covers 0-7:

// We do not support other buttons.
_ => return Err(could_not_parse_event_error()),

So a terminal that forwards X1/X2 clicks (e.g. kitty, foot, WezTerm) currently causes crossterm's event parser to error rather than emit an unrecognized-but-harmless event.

Describe the solution you'd like

Add MouseButton::X1 and MouseButton::X2 variants, and decode button numbers 8/9 in parse_cb into Down/Up/Drag(MouseButton::X1|X2) the same way 0-2 are handled today.

MouseButton isn't #[non_exhaustive], so this is a breaking change for any downstream exhaustive match. Given crossterm is pre-1.0, I'd assume that's fine in a minor bump, but wanted to flag it rather than assume - happy to add #[non_exhaustive] as part of this if you'd prefer that over a plain breaking addition.

I've only verified the Unix/SGR path so far. The Windows path (src/event/sys/windows/parse.rs) goes through crossterm_winapi::ButtonState, and I haven't confirmed whether that exposes XBUTTON1/2 - happy to scope this issue/PR to Unix first and follow up on Windows separately if that's cleaner.

Describe alternatives you've considered if any

None at the parser level - X1/X2 has to be decoded here since it's now silently dropped as a hard parse error. Consumers could work around this by binding X1/X2 to a modified keypress in their terminal's own mouse-remap config, but that's a per-user workaround, not something crossterm can rely on generally.

Additional context

Motivating downstream use case: domcyrus/rustnet#274 wants X1/X2 for mouse-driven back/forward navigation between views, and the maintainer confirmed crossterm doesn't currently support this.

I'd like to work on this if the approach above looks reasonable.