Distinguish transparent colors from undefined props

[ngocdevv]

Summary:

Fixes #58085.

Android represents both an undefined color and explicit transparent black as ARGB 0. SharedColor previously compared only that raw value, so Props 2.0 considered an explicitly supplied transparent color equal to an absent prop and omitted it from the mount diff.

This change tracks color presence separately from the platform value and includes it in equality, boolean conversion, and hashing. Platform parsers and the few call sites that intentionally produce an undefined color now preserve that state explicitly.

Changelog:

[ANDROID] [FIXED] - Preserve explicitly transparent colors during Props 2.0 reconciliation.

Test Plan:

• Added ColorTest.testTransparentColorIsDistinctFromUndefined.
• Compiled and ran a standalone regression harness against Android Color.cpp; it failed before this change and passes afterward.
• Built ReactAndroid CMake Debug for arm64-v8a successfully.
• Validated all 9 ReactCommon, ReactAndroid, and ReactApple C++ API snapshots against Doxygen 1.16.1.
• Ran targeted clang-format and git diff --check.

[Abbondanzo]

By leaking Android details into the SharedColor implementation, UndefinedColor loses its meaning. Instead, this responsibility should be shifted into the HostPlatformColor struct for Android to mirror what iOS, macOS, and Windows do: define undefined Color separately. You could define a new struct for Android

struct Color {
    int32_t value{0};
    bool isDefined{false};
    constexpr Color() = default;
};

This way Color{} != Color{0}

It's a bit less surgical to do it this way, but avoids future footguns if anyone were to reach for UndefinedColor