PlatformColor lazy fallback: honor a raw-color fallback on iOS and macOS (native) (#57556)

[Abbondanzo]

Summary:

An implementation for the RFC in react-native-community/discussions-and-proposals#1008

This is the first diff in a stack that adds an optional trailing {fallback: '<raw color string>'} argument to PlatformColor(...). The fallback is carried lazily to native and parsed only when every supplied color token fails to resolve. This diff wires up the iOS and macOS native color resolvers to honor that fallback; a later diff adds the JS argument that emits it, so on its own this change is a no-op for existing call sites.

To distinguish a genuine miss (no token resolves) from a token that legitimately resolves to a transparent color, the semantic-color resolver gains an OrNil variant:

• RCTPlatformColorFromSemanticItemsOrNil returns nil on a miss instead of collapsing to clearColor. RCTPlatformColorFromSemanticItems keeps its existing non-null contract by wrapping the OrNil variant.
• On Fabric, Color::createSemanticColor returns the undefined-color sentinel (a null underlying UIColor) on a miss, so PlatformColorParser.mm can apply the fallback only on a true miss and otherwise render transparent exactly as before.
• The fallback string is parsed with the shared CSS color parser (parseCSSProperty<CSSColor>), so transparent/rgba(0,0,0,0) are honored rather than mistaken for a parse failure.
• On the iOS Paper (legacy) path, RCTConvert.mm parses the common hex forms (#RGB, #RGBA, #RRGGBB, #RRGGBBAA, alpha last) as the fallback when every semantic name misses.

This spans the xplat iOS/macOS graphics resolvers and the vendored third-party/react-native-macos copies.

Changelog:
[Internal] - PlatformColor: iOS/macOS native support for a lazy raw-color fallback

Differential Revision: D111837102

[meta-codesync]

@Abbondanzo has exported this pull request. If you are a Meta employee, you can view the originating Diff in D111837102.