When using a menu bar without Wayland popup support, the menu items are
unclickable, as redrawing is never requested.
So, request a redraw after opening so the overlay menu is created and
drawn immediately.
`Dropdown::new` (the plain constructor used by any non-applet consumer) leaves `window_id`/`on_surface_action` unset, which routes the widget's `overlay()` impl to the in-window overlay path rather than the surface-action-based popup path. On that path, `update()`'s `open` closure and its close counterparts only ever requested a redraw inside the `#[cfg(wayland_platform)] if let Some(...)` block gated on those fields being set — so for the common case, opening or closing a dropdown flipped `is_open` with no redraw requested at all. The stale frame stuck around until some unrelated later event (e.g. cursor motion landing on the now-open/closed menu's bounds) forced a repaint,
making the menu appear to not open until the mouse moved, and not close until the same thing happened again on the way out.
Add an unconditional `shell.request_redraw()` at each of the three `is_open` transitions that don't already publish a Message of their own (an actual option selection already triggers a normal Message-driven redraw through the app's own update cycle, so that path needed no change):
- `open`: right after `is_open` is set true, ahead of the wayland-only surface-action block.
- the `close_operation` branch of the open/close operation state machine (`Id`-based programmatic close).
- the click-outside-closes-it branch of the mouse/touch press handler.
Fixes#1395
This calculates the `bar_height` based on the size of the Circular by default, so that ones with a small size don't have visual issues caused by a fixed height.
Also fixes the `track_radius` calculation, which caused the widget to appear smaller than it should be.
