Review/refactor .in/.inner.in/declaredIn

[ssalbdivad]

The way we represent and deeply extract the input/outputs of a type including morphs has changed over time, and there have been some bugs recently where the wrong variant is used (e.g. ).

In the case of #1170, the following root cause in morph.ts is a good example of why this kind of review is necessary:

			...defineRightwardIntersections("morph", (l, r, ctx) => {
				const inTersection =
                // this innocuous looking `l.in` also extracts nested morphs,
                // removing them from the intersected type.
                // this was fixed by changing l.in to l.inner.in here
					l.inner.in ? intersectOrPipeNodes(l.in, r, ctx) : r
				return inTersection instanceof Disjoint ? inTersection : (
						ctx.$.node("morph", {
							...l.inner,
							in: inTersection
						})
					)

declareIn/declareOut have added some ambiguity to how various intersections should be handled. Their benefit is obvious, but those details need to be hammered out and defined clearly, potentially with some internal renaming so it is clear which variant should be used in any given case. Those have also already led to at least one bug.

Also as part of this, morphs should be converted to a single array with no .in property so it can be handled consistently when extracting input/output.