Add conic-gradient() and repeating-conic-gradient()

[jhaygood86]

Feature

Adds conic-gradient() and repeating-conic-gradient() (CSS Images 4 §3.4):

conic-gradient(red, blue)
conic-gradient(from 90deg, red, blue)
conic-gradient(from 45deg at 30% 70%, red, blue)
conic-gradient(red 0deg, blue 90deg, lime 180deg)
repeating-conic-gradient(red, blue 30deg)

Implementation

A real ConicGradientConverter (not a pass-through). Two things distinguish a conic gradient from linear/radial:

1. Prelude — [ from <angle> ]? [ at <position> ]? instead of an angle or shape/size.
2. Stops are angular — <angular-color-stop> positions its stops with an <angle-percentage>, not a <length-percentage>.

To support (2) cleanly, the stop-position parser in the shared GradientConverter base becomes an overridable member (StopPositionConverter), defaulting to the existing length-or-percent converter — so linear and radial are byte-for-byte unchanged — and the conic subclass overrides it with angle-or-percent.

A first comma group that begins with a color, angle, or percentage is a stop, not a prelude, so ConvertFirstArgument rejects it and the caller treats it as the first stop (e.g. conic-gradient(red 0deg, …)).

The converter is wired into GradientConverter, so every <image> property (background-image, list-style-image, …) accepts it.

Tests

12 cases in Gradient.cs:

• 8 legal, asserting the exact serialized value: bare, from <angle>, at <position>, both, angle stops, percentage stops, 1turn, and repeating-conic-gradient
• 3 illegal: from red (needs an angle), at, (needs a position), red 0px (conic stops are angular, not length)
• a guard that linear and radial gradients still parse (the base-class refactor)

The full suite (1263 existing tests) stays green, and all seven target frameworks build with no new warnings.