remove youtube_player_flutter and flutter_inappwebview to fix common related issues in flutter_quill_extensions

[EchoEllet]

We're having many issue and reports to issues that caused by flutter_inappwebview which is required and needed by youtube_player_flutter which is a dependency in flutter_quill_extensions

Embedding platform Webview in the editor causes performance issues, rebuilding the platform widget consistently makes the video reload many times on some platforms, making the editor unstable even when not interacting with the platform widget, increasing the bundle size, requiring more transitive dependencies and more manual set up for the web.

We did plan on introducing this change in the next major release by introducing a separate package (#2276), or by using the download URL to load the video without the iframe (#1916), directly using a normal video player widget (which violates the terms of service of YouTube) and some other solutions by it seems that we're getting more reports outside of GitHub, and I did have some issues while working on an outdated branch.

Removing those dependencies was something we planned for a while ago, pubspec by default use the latest compatible version of any dependencies as it assumes it confirms to Semantic Versioning and they have introduced macOS and Windows support in a minor version, which causes to have build failure for the users and for maintainers working in outdated branches, we do find it a bit confusing since we didn't manually updated the version of any related dependency.

It seems that flutter_inappwebview_windows and flutter_inappwebview_macos was introduced as dependencies of flutter_inappwebview 6.1.0, where they were experimental and causing build failure even on Android (on Windows machine). It seems that they working hard to introduce fixes as fast as possible, see flutter_inappwebview #2294 and flutter_inappwebview #2288.

I'm grateful for their efforts to the open source community and the support for macOS and Windows even if it introduce many issues, however, I do think those dependencies should be included in the user project and not as part of this project, especially we don't heavily depend on it, if this was a payment package to a web service (that doesn't have public web API) or something related then it would be critical to have it, the solution we have is not ideal for many users, and more users detaching flutter_quill_extensions and eventually flutter_quill.

We're currently trying to focus on the current issues we have, we prefer to not have more on the surface for more issues at the moment.

We have four choices:

• Do nothing for now and wait for issues to be fixed, then remove it once we're ready for a major breaking change which we are not and should not introduce a breaking change release for this change for many reasons we have discussed across multiple issues, see #2259 Not being able to build the project and look for workaround is an experience we're looking to
• Introduce a breaking change in non-minor version 10.8.0 and include notes for users in CHANGELOG.md, provide a quick experimental solution to allow users to introduce their own solution, currently, we can't plan for a stable solution as we have more many issues that need time and introducing a good solution is not a priority, we also have discussed about this across multiple issues, see #2270
• Separate the version of flutter_quill_extensions right away and only introduce a breaking change for the extensions package. Introducing a breaking change for flutter_quill is currently not an option due to the reasons we have discussed in many issues (we don't have a specific issue to keep track of those discussions due to the lack of time), this will break our current workflow which also have issues, I prefer to not use such solutions as we still busy with other issues and need better planning We have more discussions and plans to organize things and packages, don't want to make quick decisions since we have made enough
• Use a different package or load the video using the download URL, possibly violate YouTube's terms of service, but not necessarily, previously I saw some apps that use the download URL without violating the terms of service, I'm not sure if there are use cases or if what they meant that we should not download videos to the user device using the download URL or if we're allowed to only play the video in video player indicating that this is a youtube video with the youtube video URL (not the download URL) and with some indicators to make it clear this is not our video, for web this can be solved by simply using iframe with platform-specific check which still cause issues even on Flutter web. Can violate the terms of service and cause other bugs/issues, see youtube_explode_dart #282

If fixing this issue with a breaking change in a minor issue is okay for most users, then we might introduce it, it shouldn't cause any issues for libraries and packages in pub.dev (see packages that depend on flutter_quill_extensions), we also could simply make it so that it would revert the video as a video link, allowing the user to press the link and play it on Youtube app as they expect, also it's might not very common that users copy video URL that's YouTube specific and then insert it in the editor.

See #1888, #2276, #1916, #2280, #989 for related issues.

[EchoEllet]

@singerdmx @CatHood0 @AtlasAutocode Need to know which method you prefer to handle this situation before introducing any change.