[core] Decouple platform_interface from Flutter for pure-Dart web

### Context & Problem

Recent cleanups (#18604, #18624) removed `package:flutter/foundation.dart`, `package:flutter/material.dart`, and `package:flutter_web_plugins` imports from `*_platform_interface` data models and `firebase_core_web`. Because FlutterFire web implementations (`firebase_core_web`, `firebase_auth_web`, `cloud_firestore_web`) are built on `dart:js_interop` and `package:web`, they can compile to JS and Wasm GC without pulling in `dart:ui` or the Flutter engine.

However, non-Flutter Dart web frameworks (e.g. Jaspr) and pure-Dart environments cannot resolve these packages using standalone `dart pub get` because `firebase_core_platform_interface` (and sibling `*_platform_interface` packages) still declare `flutter: sdk: flutter` in `pubspec.yaml`.

The sole remaining reason `*_platform_interface` depends on `flutter: sdk: flutter` is that it bundles the default `MethodChannel*` implementation (`package:flutter/services.dart`). Meanwhile, `package:plugin_platform_interface` itself is already 100% pure Dart.

### Proposed Options

We would like feedback from the maintainers on two architectural options to remove the `flutter: sdk: flutter` dependency from the platform interface layer:

#### Option A: Move `MethodChannel*` out of `*_platform_interface` (In-Place Pure Dart)

- Move `MethodChannelFirebase` (`package:flutter/services.dart`) from `firebase_core_platform_interface` into the app-facing `firebase_core` package (or a dedicated `firebase_core_method_channel` subpackage).
- Remove `flutter: sdk: flutter` and `environment: flutter:` from `firebase_core_platform_interface/pubspec.yaml`.
- **Pros**: Zero new packages; `*_platform_interface` becomes 100% pure Dart immediately.
- **Cons**: Technically a breaking change for external consumers or test suites that directly instantiate `MethodChannelFirebase` from `firebase_core_platform_interface` (requires scheduling for the next major version bump).

#### Option B: Extract Pure-Dart Leaf Package (`package:firebase_common` / `*_interface`)

- Extract pure-Dart platform contracts and shared domain models (`FirebaseAppPlatform`, `FirebaseOptions`, `FirebaseException`, `Timestamp`, `GeoPoint`, etc.) into a zero-dependency pure-Dart package (e.g. `package:firebase_common`).
- Have `*_platform_interface` re-export these types alongside `MethodChannel*`, while `*_web` packages depend directly on the pure-Dart package.
- **Pros**: 100% backwards-compatible; requires no major version bump to existing `*_platform_interface` packages; enables code sharing with server-side `firebase-admin-dart`.
- **Cons**: Introduces a new leaf package to publish and maintain in the monorepo.

### Acceptance Criteria

- [ ] Select preferred direction (Option A vs. Option B) for decoupling `MethodChannel*` (`package:flutter/services.dart`) from the pure-Dart interface layer.
- [ ] Confirm whether pure-Dart platform interfaces should standardize exclusively on `FirebaseException` rather than catching/throwing `PlatformException`.

Start by reading firebase_core_platform_interface/pubspec.yaml and the MethodChannelFirebase implementation, then compare the sibling *_platform_interface and web packages described in the issue. Review Option A versus Option B and the FirebaseException/PlatformException contract with maintainers. Done means a direction is selected and the acceptance criteria are resolved.

Written by the indexing model from the issue text.