Reimplement the hyperbracketed operations to avoid hypernests #6
Description
The data structures Punctaffy defines for hypersnippets may be algebraically interesting, but they're difficult to make safe and efficient. We could try to push more of the costs for verifying that a hypernest or hypertee is internally consistent to construction time, but even then, our ADT-like constructor operations pose costs for constructing hypersnippets that are likely quadratic or worse, due to each constructor call having to traverse its input to verify that its hypersnippet shapes match up.
We don't have to use hypernests in the implementations of operations like list-taffy-map and taffy-quote. We can probably just use hyperstacks, which would impose a cost that's likely superlinear (due to certain popping operations having to check the given dimension against the dimensions of multiple candidate hyperstack frames) but typically linear in practice (since the number of dimensions we're actually dealing with only exceeds 3 or 4 if we're doing something really wild).
Where these operations need data structures, we'll likely be able to reuse punctaffy/syntax-object/token-of-syntax.
When we're revising things like list-taffy-map, list-taffy-bind, and list-taffy-let, we should basically embrace that they're quoting operations. Some call sites may need to use escape sequences to express certain code, particularly if that code somehow shadows the meaning of hyperbracket notations or defines local ones. A language that's based on hypersnippets from the very start of its formalism may constrain how hyperbracket notations can be shadowed or defined, and in so doing, it can remove the need for list-taffy-map to use escape sequences. We should keep on allowing list-taffy-map to be used in ways that resemble the more proper form it would take in those languages, but whenever we introduce escape sequence taffy-notation?, we should feel free to add support for it to list-taffy-map and friends.