macOS: Expose new Tao APIs

[betamos]

These changes exposes Tao APIs that are only affecting MacOS:

• Window.show_application()
• Window.hide_application()
• Window.set_application_policy_at_runtime(..)

Following precedent set by set_activation_policy, these APIs are all target-gated to MacOS only.

What kind of change does this PR introduce?

• Bugfix
• Feature
• Docs
• New Binding issue #___
• Code style update
• Refactor
• Build-related changes
• Other, please describe:

Does this PR introduce a breaking change?

• Yes, and the changes were approved in issue #___
• No

Checklist

• When resolving issues, they are referenced in the PR's title (e.g fix: remove a typo, closes #___, #___)
• A change file is added if any packages will require a version bump due to this PR per the instructions in the readme.
• I have added a convincing reason for adding this feature, if necessary

Other information

Related to #2358.

[JonasKruckenberg]

I think some more explanations would be helpful here, what does hiding the app mean in detail? Does it affect the dock icon? Does it affect Mission Control? Or the app quick switcher?

[betamos]

I'd love to, but the only way to know would be experimental. Apple is deliberately vague about this, probably because things like dock and mission control are subject to changes across MacOS versions. Being more detailed than Apple's own docs won't be much help. Here's an example of what we call show_application:

https://developer.apple.com/documentation/appkit/nsapplication/1428761-unhide?language=objc

[amrbashir]

This is the same as #3689, we won't merge this anytime soon. These api will have to wait for v2.

[betamos]

@amrbashir noted, and sorry for creating yet another duplicate PR. Same story, I didn't know this was already implemented. For context, these features are important for MacOS apps to behave in line with user expectations, that's likely why we both arrived at the same features.

Are we blocked due to feature freeze for 1.0 or because we haven't yet approved the API design? If the latter, we could parallelize the design discussions without putting load on the team.

Note the difference between this PR and #3689:

• This PR also contains the set_activation_policy_at_runtime method.
• This PR exposes methods on Window whereas the other exposes them at AppHandle (which is arguably a better design)

[amrbashir]

It is blocked because we can't introduce new APIs that isn't audited so it will have to wait for v2 so it can be audited.

[lucasfernog]

@betamos we've merged the show/hide APIs from #3689, can you open a new PR for the set_application_policy_at_runtime API, following the same strategy (adding the APIs to App and AppHandle instead of Window)?