Move FluentTheme code to new FluentUI_common module

[mischreiber]

Platforms Impacted

• iOS
• visionOS
• macOS

Description of changes

This PR lights up FluentTheme and various other low-level Fluent utilities on macOS by moving them to a new cross-platform module, FluentUI_common. To walk through the changes, I've split the diff into four commits.

320e374: Create FluentUI_common target

• Nice and easy: updating Package.swift to specify a new build target, FluentUI_common.
• Updating both FluentUI_macos and FluentUI_ios to depend on this new target.

e6b2370: Move common files to FluentUI_common directory

• This moves many FluentTheme- and token-related files to the new FluentUI_common directory, with almost no changes.
• First exception to this is Color+Extensions.swift, which hooks into the new macOS-specific DynamicColor integration found in NSColor+Extensions.swift.
• Second exception is FluentUI.swift, which now also exports FluentUI_common in addition to the platform-specific module. This means users can continue to simply import FluentUI and get the code they expect.

069ec24: Add import FluentUI_common to iOS files

• This is a big commit, but nothing interesting is happening.
• I've just added import FluentUI_common to every remaining file in FluentUI_ios, now that so much of the support structure of Fluent iOS has been moved to that library.

1e07c89: Add import FluentUI_common to tests

• Same for tests :)

Binary change

TBA, will be testing the built app to see impact.

Verification

Ran all automation on both iOS and macOS, and got the same level of success as before my change (there are some failing Notification tests that we should fix later).

Also added a direct FluentTheme reference in the new FluentUI demo app, demonstrating the ability to access Fluent colors from macOS.

Before	After

Pull request checklist

This PR has considered:

• Light and Dark appearances
• iOS supported versions (all major versions greater than or equal current target deployment version)
• VoiceOver and Keyboard Accessibility
• Internationalization and Right to Left layouts
• Different resolutions (1x, 2x, 3x)
• Size classes and window sizes (iPhone vs iPad, notched devices, multitasking, different window sizes, etc)
• iPad Pointer interaction
• SwiftUI consumption (validation or new demo scenarios needed)
• Objective-C exposure (provide it only if needed)

Microsoft Reviewers: Open in CodeFlow

[thomasjross]

This could be a good excuse to rename Color+Extensions.swift to something more descriptive and then introduce something like DynamicColor+UIKit and DynamicColor+AppKit (or similar names)

[mischreiber]

I see the appeal, but two reasons I'm inclined to keep the current names for now:

1. Color+Extensions.swift isn't purely based around DynamicColor; it also adds Color.init(hexValue:). In fact, the public API is half and half, and doesn't even mention DynamicColor at all.
2. Our convention in Fluent is to name extension files after the class they're extending. Since the files in question extend Color, NSColor, and UIColor, they should all be named [Color|NSColor|UIColor]+Something.swift. We could change the +Something part, but we run into the same problem that there are multiple kinds of additions to each class, not just DynamicColor.

[anandrajeswaran]

Is this still needed? Or can we just make this file not compile for macOS?

[anandrajeswaran]

That a bunch of stuff (well actually not that much, but not zero) now has to be exposed publicly when it wasn't before makes me second guess myself. There's no way to share code selectively across platforms with use of path includes/excludes in Package.swift/MicrosoftFluentUI.podspec?

[anandrajeswaran]

Basically, is it actually gross to do this without introducing a new module?