Add macOS and tvOS support to EpoxyCore

[calda]

Opening this PR as a discussion starter. Consider this a proof-of-concept.

Starting in airbnb/lottie-ios#2092 we're using EpoxyCore's SwiftUI UIViewConfiguringSwiftUIView to provide a SwiftUI wrapper for Lottie's LottieAnimationView UIView.

EpoxyCore currently only officially supports iOS, but Lottie also supports tvOS and macOS.

• tvOS uses UIKit, so EpoxyCore already supports tvOS with basically no code changes.
• macOS uses AppKit, so there are a decent number of differences

If EpoxyCore supported macOS, we could provide Lottie SwiftUI support on all Apple platforms. This lets you, for example, create a single SwiftUI app which uses Lottie and can be ran on all Apple platforms.

There are two types of changes that have to be made to support macOS / AppKit:

1. Replace references of UIView with NSView (etc). This PR implements that with a typealias UIViewOrNSView which resolves to either UIView or NSView depending on the platform. Most of EpoxyCore compiles successfully with just these changes.
2. Add #if os(macOS) as necessary where UIView and NSView have different APIs or behaviors. The most important example of this is in SwiftUIMeasurementContainer, where the behavior has to be slightly different on macOS.

To me these changes feel relatively noninvasive. It's especially reassuring that there are only a few places where we have to implement different runtime behavior depending on the platform.

What do folks think?

If we're ok with this direction I'll work on further productionizing these changes, e.g. by adding more code comments and by adding CI jobs that test the tvOS and macOS support.

---

Example screenshots from a multiplatform SwiftUI app using Lottie, running on macOS and tvOS with a single codebase using the changes in this PR:

macOS / AppKit

tvOS / UIKit

Source code of example:

struct ContentView: View {
  var body: some View {
    HStack {
      VStack {
        LottieView(animation: LottieAnimation.named("Samples/LottieLogo1")!)
          .looping()
          .frame(maxWidth: 100)

        Text("maxWidth: 100")
      }

      VStack {
        LottieView(animation: LottieAnimation.named("Samples/LottieLogo1")!)
          .looping()
          .frame(maxHeight: 100)

        Text("maxHeight: 100")
      }

      VStack {
        LottieView(animation: LottieAnimation.named("Samples/LottieLogo1")!)
          .looping()
          .resizable()

        Text("resizable")
      }

      VStack {
        LottieView(animation: LottieAnimation.named("Samples/LottieLogo1")!)
          .looping()

        Text("intrinsic content size")
      }
    }
    .ignoresSafeArea()
    .frame(maxWidth: .infinity, maxHeight: .infinity)
  }
}

[thedrick]

This is really awesome @calda I made some comments and am curious what your thoughts are. We will want want this to be a major version bump if we do end up making breaking naming changes

[brynbodayle]

Overall approach LGTM

[calda]

This PR is ready for review now @airbnb/epoxy-ios-maintainers

[calda]

Should we release these changes as 0.10.0 after merging this PR or should I leave it under "Unreleased"? (Somebody else would have to cut the release since I don't have write access)

[thedrick]

@calda I'm wondering if we should cut a release before these changes, and then do a new release after these changes have been merged so we can include the other non-breaking changes currently unreleased?

[calda]

Good idea, that makes sense. We could release 0.9.1 and then 0.10.0?

[calda]

Well, looking at the CHANGELOG we've only every cut releases like 0.6.0, 0.7.0, 0.8.0, 0.9.0. So I guess this should be 0.10.0 without the breaking changes (not 0.9.1) and then 0.11.0 with the breaking changes?

[calda]

Here you go: #144