fix DotExpr for fusions and improve missing field semantics

[mccanne]

This commit makes DotExpr's work with fusion and nones. There is currently a slow-path defuse whenever a none value or missing-field error is encountered. We can improve this later.

In making these changes, we realized it would be better semantics for a reference to a non-existent field always return an error even for the "?." operator. Instead, ok() with a none operator should be used when missing fields are expected.

Ok-pushdown will be added in a subsequent PR where the defuse step required to create the structured error can be avoided when we know the dot operation is wrapped in an ok() or is_ok(). We added the flag to the DotExpr struct but still need to wire it up.

[nwt]

Nit: Use a type switch.

Suggested change

	if _, ok := vec.(*vector.None); ok {
	return true
	}
	if vec, ok := vec.(*vector.Fusion); ok {
	return hasNone(vec.Values)
	}
	if vec, ok := vec.(*vector.Dynamic); ok {
	return slices.IndexFunc(vec.Values, hasNone) >= 0
	}
	if super.IsOptionType(vec.Type()) {
	return hasNone(vec.(*vector.Union).Dynamic())
	}
	switch vec := vec.(type) {
	case *vector.None:
	return true
	case *vector.Union:
	return super.IsOptionType(vec.Type()) && hasNone(vec.Dynamic())
	case *vector.Fusion:
	return hasNone(vec.Values)
	case *vector.Dynamic:
	return slices.IndexFunc(vec.Values, hasNone) >= 0
	}

[nwt]

Nit: okPush is a pretty opaque name. Maybe call it something more intention-revealing, like skipMissingDefuse?

[mccanne]

It's ok pushdown. What rather than how