Improve interoperability with native UI frameworks

[stackotter]

This PR introduces various APIs related to improving interoperability between SwiftCrossUI view code and native UI frameworks. This includes:

• Making it easier to make platform-specific modifications to the native widgets behind SwiftCrossUI views via the inspect family of modifiers
  • This allows people to work around missing SwiftCrossUI features and to access niche platform-specific APIs that we don't plan on wrapping
• Enabling the hosting of SwiftCrossUI views in native apps via the FooHostingView family of types
• Enabling the hosting of native views in SwiftCrossUI apps via the FooRepresentable family of types
  • (SwiftCrossUI already NSViewRepresentable, UIViewRepresentable and UIViewControllerRepresentable, but we still need to introduce similar APIs for the non-Apple backends)

So far I've completed the inspect family of view modifiers (which are housed in each backend), and introduced an AdvancedCustomizationExample app to showcase these new advanced customization APIs.

[stackotter]

I've created the FooRepresentable family of protocols now. Next I'll working on the FooHostingView family of views and then I'll come back and try to improve the experience of using the FooRepresentable protocols. The naming of the protocol requirements currently differ in just enough ways to be annoying when copy and pasting an existing implementation to adapt it for a new backend. Some suggestions were given in the Discord server that I'm considering going with.

The hardest part of implementing the FooRepresentable family of protocols was integrating with the layout system of the underlying native frameworks. Each framework exposes a different measurement API with unique limitations. The WinUI one is probably the most fragile because I had to apply a similar hack to the one used to get natural sizing working correctly; any WinUI elements that SwiftCrossUI itself doesn't already use are likely to have incorrect sizes before the first render. The other dodgy implementation is the GtkBackend one. It seems to work well enough, but throws a bunch of warnings because we occasionally measure with less height/width than the underlying widget can work with. I've searched around for APIs that would tell us what these minimum workable dimensions are, but I haven't found any yet. The issue is that when measuring you provide one dimension and get minimum/natural dimensions for the other dimension, but Gtk never actually tells you how much of the provided dimension it wants to use. Gtk 3 doesn't seem to care.