[Web] Handle WebView Full Screen callbacks via state

[sampengilly]

I tried to write a test for this but so far haven't gotten things to work in that environment. I checked the behaviour during whilst implementing the feature by fullscreening youtube videos in the sample app and showing a dialog with the provided view.

[sampengilly]

Probably best that I rebase this onto #1097 once that's merged

[bentrengrove]

This one might be venturing into an area we probably don't want to support from the Accompanist version, I almost feel like people should fork their own implementation if they need this functionality.

The biggest part that worries me is that custom view and what that could mean if you want to pass in a ComposeView for it or a normal view and all the can of worms involved in that.

[sampengilly]

Yep, with the exposure of the WebChromeClient it makes a little less sense to support this explicitly. As for the custom view, it's essentially just what the WebView has given us. There could be an argument over whether it should be exposed as-is or wrapped in a composable and then exposed.

There also seems to be some ambiguity in the docs stating that if the showCustomView/hideCustomView methods are overridden at all then it will be taken to mean that the WebView supports it, and if they're not overridden it will be taken to mean that it doesn't support it. I couldn't find anything concrete to determine if an empty override method with a single super call is somehow seen as supporting fullscreen just by existing even if there's no actual implementation.

[bentrengrove]

I'm going to go ahead and say that this is not something we want to support right now. I am hoping to get the Web wrapper in to a pretty stable state before Accompanist has it's next stable release so will be slowing down on adding new features.

Thanks for the PR again though.