Add the 'Blend Shapes' and 'Origins to Polyline' nodes; generalize the 'Morph' node to >2 states

[Keavon]

Closes #2316

This also introduces the Progression widget type for a t value along one or multiple parts (such as subpaths or vector elements):

Morph node

This changes the behavior of the Morph node to work more like the Boolean Operation node, generalizing it from two inputs to any number of inputs by reducing a group of vector shapes to a single shape along the morph progression. This would previously zip the multiple elements in the starting, and ending, states and morph each pair in unison; this is no longer supported and is a breaking change, but if only a single element was the morph source and target, that has an automatic migration to handle the change without breakage.

capture_18_.mp4

Blend Shapes node

A network node that calls Morph repeatedly and produces a chosen number of instances.

capture_17_.mp4

Origins to Polyline node

A network node that creates a polyline stringing together every object in the table it is given. This is designed to be used alongside the Blend Shapes node to control the curvature of the interpolation path (such Path tool changes encoded in the Path node) using this setup:

capture_21_.mp4

[Keavon]

I need to fix the test but this is otherwise open for review, thanks @TrueDoctor @adamgerhant.

[adamgerhant]

I think this should be done with the "FlattenVectorNode", the input to this node should be Table, and in the future the automatic type conversion can be added

[Keavon]

I thought about automatic type conversion but decided we probably don't want that, because we can't guarantee that will always be desired. Going from a less pure to more pure form of data is lossy (we throw away non-vector objects, in this case) and opinionated (do we want to flatten deeply or only one level while discarding or merging the geometry of deeper levels?) and will need to vary per node based on what makes sense for each one. This allows the node to easily reuse this functionality if needed, but not let data get destroyed by the type conversion system if it doesn't encode user intent.