Thanks for this PR.

I wonder if it might be a good idea to add a new constructor that allows passing in a versioned struct with options. The struct could perhaps have the same members as the existing constructor's parameters and other things such as a window title, initial size, and also backend-specific things such as a pointer directly to CoreWebView2EnvironmentOptions or an abstraction that can be shared by all of the backends.

The way the current webview class concerns itself with pretty much everything makes it a bit complicated when introducing new features.

For example, it isn't clear to me how options for other backends would be passed in the future and who would be responsible for the memory. If we need to pass any other type of options than CoreWebView2EnvironmentOptions for WebView2 or other backends, we would need to add another defaulted parameter for that to avoid breaking existing code.

When it comes to the C API, I'm afraid we can't change webview_create(). There's currently no way for the caller to let the library know which versions of the header its using. They could be calling webview_create() with 2 or 3 arguments and the library might crash due to expecting a different number of arguments.

Especially here it would help to have a versioned struct so that the function signature doesn't have to change in the future. We would have to add a new function though such as webview_create_with_options() because we can't overload webview_create().

I made an attempt to improve things in PR #766 some time ago, and I sometimes take bits of code from it, but it's pretty much abandoned.

The route with an options struct seems like a good path to me, at least for the C API.

In the long run, the main API would ideally not be one god class called webview, but something that has more clear scopes. That's an idea at least for the future.