Add NSViewRepresentable for AppKit & support Swift 6 concurrency.

[furby-tm]

Note: this revision bumps the minimum macOS version from v10.15 to v11 though we should probably do as the CI compiler error for the examples indicate and maintain backwards compatibility via #available macros.

Leaving the error in for now, to make obvious there was a minimum version bump and discuss how we should best move forward before merging this in.

[stackotter]

Thanks for the PR 🙏 just requested a few changes

[stackotter]

Looks good now 🙏

[stackotter]

Actually, where did the asWidget and update methods for NSViewRepresentable's View implementation go? I don't think the code works in its current form (haven't tested yet though).

[furby-tm]

Actually, where did the asWidget and update methods for NSViewRepresentable's View implementation go? I don't think the code works in its current form (haven't tested yet though).

Lol, oh really? Yeah I need to actually test it -- I simply compiled it is all... what would the implementation look like for those methods? I simply removed them because they were calling into that BaseWidget class that you had me remove:

final class RepresentingWidget<Representable: NSViewRepresentable>: BaseWidget
{}

so I assumed those methods were not necessary.

Here are the removed functions that were utilizing that underlying BaseWidget class:
0d34485#diff-e04a1f95fd782aab32cd2305bc927fc9466a10cda97b441b7d8c78c5d7340f7eL124-L160

What did you have in mind instead?

[furby-tm]

cc. @stackotter ^

[furby-tm]

@stackotter checkout my latest revision for a implementation assumption I made on adding your update and asWidget methods back, still have not gotten around to testing it yet... but compiling it is still successful.

[furby-tm]

@stackotter upon actual testing I can confirm the latest changes in this PR allow it to work (without crashing & with expected behavior at least with my USD hydra powered viewport app).

Notable changes

• I had found BaseWidget to be quite an important implementation detail as I could not create an asWidget method implementation that did not crash without it, it's totally possible I was just missing something obvious -- but will need your eyes to look at it closer to see if it's actually necessary -- my testing told me it was though.
• The added @MainActor specification on the func makeCoordinator() -> Coordinator created a bit of a domino effect that caused me to litter many of scui's methods with @MainActor declarations - following the compiler errors all the way to a successful compilation ended in adding those declarations all the way up to App's main() function, but I suppose in hindsight at least that bit makes sense.

[furby-tm]

also this is macOS 10.15+ compliant with the #available macros being utilized here, using safeAreaLayoutGuide on more modern versions of macOS.

[furby-tm]

After coming across a thread on the swift forums, it looks like there are some issues regarding swift 6 strict concurrency and non-Apple GUI frameworks like GTK, as such I've put in place a "lopsided" approach, which minimally allows things to work with swift 6 strict concurrency but removes the @MainActor from makeCoordinator() determineViewSize.

So things should be forwards compatible, and we can open up proper support for swift 6 cross-platform once this issue is addressed:
https://forums.swift.org/t/pitch-custom-main-and-global-executors/77247/39

[stackotter]

Gonna merge this into a temp branch and test/fix things there