Trouble with DML/overlays and ensure_source_rvar

[msullivan]

In #3023 I added an xfailed insert test. A simplified version of it is

WITH                                                                      
     F := (INSERT Subordinate {name := "!"}),                             
     Z := enumerate((F,)),                                                
SELECT Z.1.0; 

and it returns an empty set. The issue turns out to be:

1. no source rvar for Z.1.0 gets advertised by enumerate, so the compiler generates a new_primitive_rvar and joins it in
2. we don't detect the insert as a dml_source of Z.1.0, and so the overlay isn't applied. This is because get_nearest_dml just looks down the main path.

I think this particular case might be easy to fix by making sure that enumerate can preserve source rvars for its elements, but there are plenty of operations that won't be able to preserve source rvars, like:

WITH                                                                      
     F := (INSERT Subordinate {name := "!"}),                             
SELECT [F][0];

Part 2 could be addressed by taking a wider view of finding dml sources; perhaps by grabbing any dml source in the ir, at all. But this made me realize that there is a more general problem here.
Consider

WITH                                                                      
     A := (SELECT UpdateTest FILTER .name = 'update-test2'),              
     B := (UPDATE A SET { comment := "foo" })                             
SELECT ((SELECT {A, B} {name, comment}));

We will output

[
  {"comment": "second", "name": "update-test2"},
  {"comment": "foo", "name": "update-test2"}
]

One object is from the select, and reflects the old data, and one from the update, and reflects the new.

If we try something where we lose track of the source rvars, though:

WITH                                                                      
     A := (SELECT UpdateTest FILTER .name = 'update-test2'),              
     B := (UPDATE UpdateTest FILTER .name = 'update-test2' SET { comment := "foo" })                                                               
SELECT assert_exists((SELECT {A, B} {name, comment}));

... then we trip an assertion. But if we remove that assertion, then we get

[
  {"comment": "second", "name": "update-test2"},
  {"comment": "second", "name": "update-test2"}
]

with both objects reflecting the old data, since we don't use the overlay.
But if we did arrange to use the overlay, then both objects would reflect the new data, which is also wrong!

Getting this right in cases like this seems pretty tricky. Possible approaches:

1. Some sort of dynamic provenance tracking
2. Reusing materialization to track any data that might be output

I'm not sure if option 2 scales to dealing with links that are also changed, and the like, though.

This issue seems very tricky to get right.