[geometry-2] Add DOMPolygon

[lukewarlow]

I also want to 2nd the mention of a DOMPolygon interface and would value this a lot more than DOMCircle as it is a nice continuation of the straight line geometry of rects and quads. The web almost has the building blocks for rich geometry in the form of spatial canvases, hand drawing without a <canvas> or systems that require collision detection. With a DOMPolygon interface and a few basic geometry utilities it would reduce the need to continually reimplement these basic affordances especially when you need them for rects, quads, and other geometry.

I've also been wondering about a DOMPath interface, which could equally (and perhaps better) be served by an isClosed property on a DOMPolygon interface. For the sake of completion, an isSimple property would round out the most basic geometry attributes.

Originally posted by @OrionReed in #602 (comment)

[OrionReed]

After thinking about this some more, I think it would make more sense for open geometry to have its own interface like DOMPath as keeping polygons closed means that all the common utilities for things like intersections (see comment).

For DOMPolygon we would of course have DOMPolygon, DOMPolygonReadOnly and DOMPolygonInit

• we likely would not validate or enforce geometry (no minimum vertices, winding order, self-intersection avoidance, etc) to match the other interfaces.
• polygons break from quads in that we can't have named p1, p2, p3, p4 and instead would need to expose a vertices() or points() function.

One question here is around point representation. It is very common for polygons to be represented as flat point arrays internally for optimisation, but the existing geometry APIs work primarily with DOMPoint objects. I'm not sure we can have our cake and eat it too here, as exposing a flattened array breaks the existing API conventions, while using a flat array internally and exposing an object-based API could be just as expensive if not more as points would be constructed on demand. I'm very open to thoughts on this, because it would be great if DOMPolygon didn't rule out high-performance applications from the start.

[Kaiido]

Do we really need a new interface when there is already a Path2D interface?
It's currently opaque, but it's always been thought this would expose its internals at some point in the future, and last time it was discussed in a F2F (about 2 years ago) everyone seemed to agree this is something we should do, though no one has invested time on it since then...