[v3 feature] Add support for MacOS Panels (PR ready)

[nixpare]

Is your feature request related to a problem? Please describe.

No response

Describe the solution you'd like

The idea is to have a component like WebviewWindow (i called it WebviewPanel) which automatically inherits every functionality of WebviewWindow and behaves like a floating window / overlay (depending on the OS).

Describe alternatives you've considered

I have found a solution which uses Go's struct embedding to extend WebviewWindow so that there is no need to touch the objective-c bindings or care about porting any change made on WebviewWindow to WebviewPanel. This is true also for the WindowOptions. However my implementation, for now, supports only MacOS NSPanel.

My implementation was first created from version v3.0.0-alpha.6, and after the v3.0.0-alpha.7 new version, I have already made a merge with the new changes. The repo is at https://github.com/nixpare/wails/tree/v3-alpha-feature/mac-panel.

You can test a working example from my repo https://github.com/nixpare/wails-mac-panel, the PR version of wails is already vendored in the code, so just wails3 dev is needed.

Additional context

Important notes on changes i made:

• application.App key bindings callback function now has application.Window as the argument and not *application.WebviewWindow
• the Objective-C WebviewWindow interface, instead of extending NSWindow directly, uses composition and now has a property for the reference to the window, which could be both a NSWindow or a NSPanel, so the keyboard events are now managed by WebviewResponder
• the C bindings that bridges the Objective-C code to Go were moved in a separate file

Additional small bugs encountered and fixes:

• Even after a Window is closed, some events are sent to the channel windowEvents, resulting in error logs printed in the console. I just have changed the log function to include the window event ID
• When sending the key combination ctrl+m, the first if statement in the Objective-C function keyStringFromEvent return "enter", now the new WebviewResponder first interprets the event.keyCode and then as a special case the event.characters string
• When sending the key combination ctrl+l, this combination never reaches the application runtime, both in the "old" and "new" versions

[leaanthony]

This sounds amazing and the changes seem reasonable. Feel free to open a PR and we can discuss details on that. Amazing work! 🙏

[nixpare]

PR opened! Let me know if I can be of any help in any way