[video_player_platform_interface] Improve seek performance on Android

[sailendrabathi]

Adds backBufferDurationMs to video_player_platform_interface

This PR has only the platform interface package changes from the main PR: #11810.

Following PR split as per Changing federated plugins

Pre-Review Checklist

• I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
• I read the [AI contribution guidelines] and understand my responsibilities, or I am not using AI tools.
• I read the [Tree Hygiene] page, which explains my responsibilities.
• I read and followed the [relevant style guides] and ran [the auto-formatter].
• I signed the [CLA].
• The title of the PR starts with the name of the package surrounded by square brackets, e.g. [shared_preferences]
• I [linked to at least one issue that this PR fixes] in the description above.
• I followed [the version and CHANGELOG instructions], using [semantic versioning] and the [repository CHANGELOG style], or I have commented below to indicate which documented exception this PR falls under[^1].
• I updated/added any relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or I have commented below to indicate which [test exemption] this PR falls under[^1].
• All existing and new tests are passing.

[gemini-code-assist]

Code Review

This pull request introduces backBufferDurationMs to VideoPlayerOptions to configure ExoPlayer's back buffer duration on Android, and adds videoPlayerOptions to VideoCreationOptions. Feedback suggests updating the assertion to allow a value of 0 (enabling developers to disable back buffering) and correcting the markdown spacing in the documentation comment for proper bold rendering.

[mboetger]

Holding on for ecosystem review

[sailendrabathi]

@mboetger, I updated the PR after approval from ecosystem reviewer.

Comment link for reference: #11810 (review)

[stuartmorgan-g]

Composing the two different options classes seems potentially confusing, but it doesn't look like the API surface ever clearly distinguished these conceptually. Since VideoCreationOptions isn't exposed to app-level clients it's probably not a big deal.

@tarrinneal As part of revisiting the video_player API surface later, it would be good to better distinguish what classes are for what steps of the process (e.g., global vs player-level options, which may have been the original intent here?), and we should also fix the fact that some of these classes are being directly re-exported from the app-facing package, which we should stop doing.