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).

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]

Since Optional includes support for .map() and .flatMap(), I wonder if you could remove this closure and instead do something like:

self.init(light: NSColor(dynamicColor.light),
          dark: dynamicColor.dark.map { NSColor($0) }

[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)

[thomasjross]

Nitpick: Not related to this PR, but there's a typo here. dynmic -> dynamic

[thomasjross]

A little surprised this didn't generate a lint warning. There's the sorted_imports rule for this, which you could opt into.