[video_player] Adopt platform-specific option/extension subclass pattern

`video_player`'s API surface has grown over time and has adopted web-specific options directly into the platform interface layer. There's pressure to do the same for Android and iOS as people want more configuration over things like ExoPlayer internal configuration. This isn't a scalable or federation-friendly solution.

We should do a one-time breaking change to adopt the pattern we are using in our newer federated plugin designs (e.g., webview_flutter), where we have a generic options class (often empty) and extension class in the platform interface, exposed at the app-facing layer, and then platform implementation packages can subclass them to add additional functionality.

Start by reviewing the video_player platform interface and app-facing API, then compare the federated options and extension pattern used by webview_flutter. Done means the generic options and extension classes are exposed at the app-facing layer and Android and iOS implementations can subclass them for platform-specific configuration.

Written by the indexing model from the issue text.