Color struct defines 1 `uint` field, and many consts typed as `int`

Why does the GDI+ `Color` struct in the metadata define a `uint` instance field and many `int` constants that would appear to be meant to be assigned to the instance field?

```cs
public uint Argb;
public const int AliceBlue = -984833;
public const int AntiqueWhite = -332841;
// ...
```

I further wonder why these constants are not typed as `Color` themselves, similar to how `S_OK` is defined with a value of 0 (the integer) but typed as `HRESULT`?

Ideally we want the user to be able to type `Color.AliceBlue` and have that represent an instance of the `Color` struct initialized to the value in `AliceBlue`. But as it is _now_, the user would have to type:

```cs
Color aliceBlue = new Color { Argb = unchecked((uint)Color.AliceBlue) };
```

That doesn't quite roll off the tongue, does it?

### Aside

Incidentally, another deviation from the pattern I (and CsWin32) are more familiar with is that these struct-value constants are defined as constants of the `Apis` class. But these color constants are defined in the struct itself. [That required a fix to CsWin32](https://github.com/microsoft/CsWin32/issues/1121). The fix was easy enough, but it _does_ mean that someone asking for the `Color` struct will immediately get ~148 color constants declared instead of having to request each named color specifically for generation. I'm on the fence on this, but maybe it's best this way so the user can easily select their chosen color from a picklist rather than referring to documentation and then naming the (presumably very few) colors they actually want to use.

Start by reviewing the GDI+ Color struct definition in the Win32 metadata and the linked CsWin32 issue 1121. Compare the existing Argb field and named constants with the desired generated C# representation. Done means the metadata and generated output consistently expose usable named Color values without regressing CsWin32 selection behavior.

Written by the indexing model from the issue text.