Fix some bugs involving union and coalescing of optional values

[msullivan]

There are a number of places that improperly handle a set that has
multiple NULL values in it:

• INSERT on single values
• UPDATE on single values
• assert_single

The assert_single case is a long standing bug that can be triggered
without much trouble. The INSERT/UPDATE bugs are new, and stem from
the new ?? on DML, since I think it that was the first thing in the
compiler backend where extra NULLS might be produced for something
with single cardinality.

Fix this by adding null checks at the consumer sites. One of the
consumer sites is set_as_subquery, and I modified update to always use
that.
I also added a helper function to add the null checks, and I'll be
going back and changing lots of other code to use the helper.

We could also flip this around a bit and try saying that we shouldn't
ever produce extra NULLs in a single set, and try to stamp it out on
the producer side, though that seems a little less consistent to me?

Fixes #6438.

[elprans]

We could also flip this around a bit and try saying that we shouldn't
ever produce extra NULLs in a single set, and try to stamp it out on
the producer side, though that seems a little less consistent to me?

Why? I have the opposite feeling that stamping out all callers could be a more error-prone whack-a-mole?

[msullivan]

We could also flip this around a bit and try saying that we shouldn't
ever produce extra NULLs in a single set, and try to stamp it out on
the producer side, though that seems a little less consistent to me?

Why? I have the opposite feeling that stamping out all callers could be a more error-prone whack-a-mole?

There is sort of a general question of "when is having NULLs output by a producer permitted" that needs to be answered.

The answer can't be "never", because at the very least we have our optional wrappers, but more generally we want some operations to always produce NULL and for us to be able to elide the optional wrapper in that case. (Object property references, parameters, json casts are current operations where this happens).

1. In this PR, I took the approach of "whenever the set could be empty", since it seemed an easy and consistent rule. But you're right that it might be whack-a-mole.
2. Another possibility is "also whenever the set could be empty, but single sets must actually output at most one row whether it is NULL or not". I think I had it in my head that this is a less consistent rule than option 1, but honestly it probably makes more sense. I think this was obeyed by everything until the conditional DML work added constructs that were implemented with unions but might have their cardinality overridden to be single.
3. Or "no extra NULLs ever, even for multi sets". This is plausible, but would require inserting NULL checks in multi operations in cases where we could not want to insert NULL checks for single operations: We don't want a NULL check for <str><json>$0 but this rule would require a NULL check in <str>{<json>$0, <json>$1}

Alright I have convinced myself that option 2 is the best.
I'll revise the PR.