Expose mouse wheel events

# Mouse wheel events silently dropped in both GL and crossterm backends

## Description

Both of bracket-lib's backends (native GL/GLFW and crossterm) catch-all scroll wheel events without relaying them, making it impossible to implement mouse-wheel-scrollable UI panels (e.g. console output, inspector, or logs).

## Affected code

**Native GL backend** — https://github.com/amethyst/bracket-lib/blob/ce9124ad744553b2576e44df44e94b0f72faa8e8/bracket-terminal/src/hal/native/mainloop.rs#L304

Note: `WindowEvent::MouseInput` ([line 262](https://github.com/amethyst/bracket-lib/blob/ce9124ad744553b2576e44df44e94b0f72faa8e8/bracket-terminal/src/hal/native/mainloop.rs#L262)) is handled for button clicks (Left/Right/Middle), but scroll wheels fire a separate `WindowEvent::MouseWheel` variant in glutin, not `MouseInput`. On some GLFW configurations scroll may also emit `MouseButton::Other(4/5)` through `MouseInput`, but this is platform-dependent and not a reliable path for scroll support.

**Crossterm backend** — https://github.com/amethyst/bracket-lib/blob/ce9124ad744553b2576e44df44e94b0f72faa8e8/bracket-terminal/src/hal/crossterm_be/main_loop.rs#L77

`crossterm::event::MouseEventKind::ScrollUp` and `ScrollDown` variants fall through the wildcard on the `MouseEventKind` match.

## Desired behavior

Scroll wheel events should be exposed through `BTerm` or the input state so that downstream consumers can query accumulated scroll delta each frame. For example, an `i32` field like `mouse_scrolled: i32` on `MouseCursor` or `InputState` that resets to 0 after being read, or a `scroll_delta` field on `BTerm`.

## Workaround

Upstream currently requires patching the dependency or forking. In our project we use Up/Down arrow keys to scroll UI panels instead.

---

Yes this description was mostly generated by AI, but if I were to manually write this, I would have never known about the relevant code in question. I need this functionality for my project