Tracking Issue: Design a new vector table-based data representation for paths, meshes, nondestructive styling, and appearance

This is a WIP brain dump for a new stab at the generalized mesh vector format. More thought is needed, but I wanted to put this down here before I forget.

# Tables

To illustrate the data dependencies amongst the proposed tables, each bullet point stores data referenced by its sub-bullet points.

- **Points**
- **Paths**
- **Bends**
- **Stroke Styles**
- **Fill Styles**

## Points

Points describe positions in the local coordinate space. On their own, they represent a point cloud.

## Paths

Paths describe the graph connectivity by listing [walks](https://en.wikipedia.org/wiki/Path_(graph_theory)) of points. Each path is a list (or sub-table?) of point ranges, each representing a polyline. At least two points must be part of a path. A closed path is one that returns to its start point, representing a face (in the context of a 3D mesh like an OBJ file describes). Collectively, all the paths represent a vector mesh of straight edges. Paths have one-to-one correspondence with an imported SVG's subpaths in terms of topology (at least, for closed or non-filled shapes). With branching topology, multiple open paths make up portions of the overall shape.

## Bends

Bends describe the curvature associated with every edge in a referenced path. They can be various types, such as splines (no handles specified), linear (essentially a no-op), quadratic (one handle), cubic (two handles), or other more exotic curve types. Handle points are references into the points table. If two paths independently specify the same edge or edges, their associated bends may curve them differently from one another.

## Stroke Styles

- #2310

Stroke styles describe all the paths corresponding to a particular stroke's paint. Each one contains a list (or sub-table?) of every path given the same style. If the style needs to change along a path, that needs to be broken up into separate adjoined paths. This is also the level at which tapered/variable stroke widths (#2207) are described, as well as [dashes](https://developer.mozilla.org/en-US/docs/Web/SVG/Reference/Attribute/stroke-dasharray), [caps](https://developer.mozilla.org/en-US/docs/Web/SVG/Reference/Attribute/stroke-linecap), [joins](https://developer.mozilla.org/en-US/docs/Web/SVG/Reference/Attribute/stroke-linejoin), and [markers](https://developer.mozilla.org/en-US/docs/Web/SVG/Reference/Attribute/marker-start).

## Fill Styles

- #2309

Fill styles describe all the boundaries corresponding to a particular fill's paint (or no paint for unfilled space). Each one contains a list (or sub-table?) of every boundary. Boundaries can be entire paths, or specific ranges of segments within a path, or the first/last half of a single segment.

TBD: how does [fill rule](https://developer.mozilla.org/en-US/docs/Web/SVG/Reference/Attribute/fill-rule) fit in, if that's applicable at the level of the whole shape? Maybe traditional SVG-style styling information and fill rule applies to a single `Table` row while the full `Table` uses the mesh fill strategy. So that might also mean some of the above descriptions need to be adjusted to work where mesh vector operates at the `Table` level while possibly `Vector` only deals with non-branching paths?