Migrate to material_ui/cupertino_ui (4.0.0)

[hyochan]

Tracks moving the package off the in-framework Material libraries and onto the
standalone material_ui / cupertino_ui packages. Raised by #426.

Context

Flutter is moving Material and Cupertino out of the SDK: contributions to the
in-framework libraries were frozen in Flutter 3.44, the standalone packages
reached v1.0.0 alongside Flutter 3.47, and formal deprecation of
package:flutter/material.dart is scheduled for an upcoming stable release.
Flutter's guidance for package authors
is explicit that packages should migrate and that the migration is a major
version bump.

Why this is not urgent

flutter_calendar_carousel exposes no in-framework Material types in its public
API. Every public type is framework core (Widget, Color, TextStyle,
EdgeInsetsGeometry, AlignmentGeometry, BorderSide, OutlinedBorder,
ScrollPhysics, Locale), intl's DateFormat, or package-owned. Material
usage (IconButton, Icons, TextButton, Theme.of, showDatePicker,
MaterialLocalizations) is confined to internal implementation.

That is exactly the case MaterialUiCompatibilityBridge covers, so apps that
have already migrated can consume 3.x today — confirmed by the reporter in #426.

Why shipping it early would be harmful

material_ui ships a one-way bridge only: a migrated app can host legacy
dependencies. There is no reverse bridge. If this package migrated now, every
consumer whose app still imports package:flutter/material.dart would break —
the calendar's MaterialLocalizations.of would resolve the material_ui type
and find nothing. That is most of the install base today.

Scope when we do it

• Target 4.0.0. material_ui 1.2.0 requires sdk: ^3.12.0 and
  flutter: >=3.44.0; this package is sdk: '>=3.8.0 <4.0.0', so migrating
  raises the floor and drops Dart 3.8-3.11 consumers.
• dart fix --code=migrate_design_widgets handles most of the mechanical
  rewrite. Keep it on a ready branch rather than merging early.
• Plan a 3.x maintenance line for backports once 4.0.0 ships.

Trigger

Start when either happens:

1. package:flutter/material.dart is formally deprecated in a stable release, or
2. demand for a migrated release accumulates.

CI risk to pre-empt

flutter analyze treats info-level diagnostics as failures. The day a stable
release annotates the in-framework libraries as deprecated, ci.yml,
release.yml, and publish.yml all go red and releases are blocked. Decide in
advance whether a narrowly scoped, documented suppression is acceptable as a
stopgap, or whether that event simply forces the 4.0.0 cut.