DatePickerButton: range selection API design discussion

## Summary

I'd like to add date-range selection to `DatePickerButton` and am looking for feedback on the API design before building a proper PR.

## Motivation

A common use case is picking a date range (e.g. a reporting period, a booking window). Right now the only way to do this with `DatePickerButton` is to place two separate buttons side by side and enforce ordering in application code. Having native range support in the widget would cover a frequent need cleanly.

## Proposed API

A new public enum replaces `&mut NaiveDate` as the selection type:

```rust
pub enum DateSelection {
Single(NaiveDate),
Range(NaiveDate, NaiveDate), // always start <= end
}
```

`DatePickerButton::new` would accept `&mut DateSelection` instead of `&mut NaiveDate`.

### Interaction model

Two complementary gestures both create a range:

- **Modifier + click** — first click sets the anchor; second click (with modifier held) sets the other end. The modifier key defaults to Shift and is configurable via `.range_modifier(egui::Modifiers)`.
- **Click and drag** — press on one day, drag to another without releasing; the range updates live as the pointer moves.

In-range days are shown in a desaturated tint of the selection colour to make the span visible at a glance.

Additional configurable shortcuts:
- `.cancel_key(egui::Key)` — close without saving (default: Escape)
- `.save_key(egui::Key)` — save and close (default: Enter)

## Breaking change

Changing the selection type from `&mut NaiveDate` to `&mut DateSelection` is a breaking change. A thin `DatePickerButtonSingle` wrapper around `&mut NaiveDate` could bridge the gap for existing callers.

## Working prototype

A working implementation is available on [`Deuracell:all-datepicker-changes`](https://github.com/Deuracell/egui/tree/all-datepicker-changes) — includes the `DateSelection` enum, both interaction models, live drag preview, and the keyboard shortcuts.

## Questions for maintainers

1. Is `DateSelection` the right shape for this, or would you prefer a different API (e.g. a separate `DateRangePickerButton`)?
2. How should we handle the breaking change — wrapper type, a new method, or accept the breakage in the next minor?
3. Any preference on how in-range days are visually distinguished?

Happy to break this into smaller PRs once the direction is agreed.

Start by reviewing the DatePickerButton API and the working prototype on the Deuracell:all-datepicker-changes branch. Compare the proposed DateSelection enum, modifier-click and drag interactions, and keyboard shortcuts with current behavior. Do not begin implementation until maintainers decide the API shape and breaking-change strategy.

Written by the indexing model from the issue text.