[enhancement] LSP should "boxcar" the processing of edit updates

### What's hard to do? (limit 100 words)

I think our policy of "redo things for every keypress" stemmed from our excitement about how fast we could parse/typecheck most meaningful things

But as transitive dependencies grow large and you edit an "interior" file in the DAG it can cause lots of reprocessing fanout, which makes the Problems pane in VSCode visibly "catch up" as it processes the impact of each character.

We should probably "boxcar" edit updates, which is to say, reprocess in bulk after some time has elapsed since the last update notification, whatever the human "standard dev or so" away from continuous keypress latency is.

I'm not sure if it's also related to us not supporting cancellation of requests, but IIRC we don't support those RPCs, maybe if we did the LSP client is already telling us "don't worry about that I have another update" and there's less logic to implement on the LSP server side.

### Current best alternative workaround (limit 100 words)

Waiting for the per-keypress updates is still not terrible, but it could be better.

### Your view of the "best case XLS enhancement" (limit 100 words)

We implement some form of box-carring of edits into a bulk reprocessing of the DAG.