[video_player_platform_interface] Platform view support

[FirentisTFW]

This PR is a subset of #8237 - it only adds platform interface changes.

Partially resolves 86613.

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene page, which explains my responsibilities.
• I read and followed the relevant style guides and ran the auto-formatter. (Unlike the flutter/flutter repo, the flutter/packages repo does use dart format.)
• 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 updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy, or this PR is exempt from version changes.
• I updated CHANGELOG.md to add a description of the change, following repository CHANGELOG style, or this PR is exempt from CHANGELOG changes.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or this PR is test-exempt.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

[FirentisTFW]

@stuartmorgan This PR changes the perception a little bit - we now should use player ID in app-facing package, and have no knowledge about texture ID there. How should I go about renaming textureId to playerId? textureId is currently used for parameter names in many platform interface methods (e.g. play, pause, setVolume). Then, it's also used for helper variables, in tests, and in other files.

What would be best way to rename it in all packages without breaking the static analysis in the meantime? What kind of changes should I add to this PR? Rename it in platform interface? Rename it everywhere? We're currently in an ugly state where we allow using platform views, but we still use textureId for parameter names everywhere.

[stuartmorgan]

I think the best way to do this is probably:

1. In this PR, rename it throughout the platform interface
2. In follow-up PRs (for iOS and Android it should just be part of the PRs that add platform view support), rename it in the implementation packages.
3. When updating app-facing package calls, like create and buildView, to the new versions, update the name there.

In order to pass CI you'll need to add // ignore directives to all the implementation packages as part of this PR, and then remove them as the implementations are updated in step 2.

[FirentisTFW]

@stuartmorgan As suggested, in this PR I renamed parameters in the platform interface and added ignores to the package implementations. The checks on the CI now fail, but I assume that this could be resolved with override: no versioning needed label?