Optimize on_did_change()

[DavisVaughan]

Branched from #363

It turns out that we are rebuilding our LineIndex at least twice on every single on_did_change() call.

• One is here, where we ignore the fact that we already had a LineIndex built for this Document

  air/crates/lsp/src/rust_analyzer/utils.rs

  Line 35 in be96e71

  let mut line_index = biome_line_index::LineIndex::new(&text);

• One is here, after we've applied all changes

  air/crates/lsp/src/documents.rs

  Lines 135 to 136 in be96e71

  	self.line_index.index =
  	triomphe::Arc::new(biome_line_index::LineIndex::new(&self.contents));

That's not super efficient! In the ~90% case where the user is just typing one character at a time, we should only be rebuilding the line index exactly 1 time.

I've folded apply_document_changes() into on_did_change() to keep all of the mutable-state-updating code close together.

The actual implementation is basically still the same, I've just had to rework things a little to do this optimization.

I had added in some logging and can confirm that we now only rebuild the LineIndex 1 time on every update as the user is typing. We typically also rebuild it exactly 1 time during a find-and-replace as well, due to how we take advantage of VS Code sending us the updates from bottom to top (so we can apply them sequentially without invalidating our line index).

I might try a PR upstream to rust-analyzer, because I'm fairly certain they have this too from looking at their code.

[DavisVaughan]

We used to just...skip (??) the file update if we were unable to convert from Position to TextRange.

This is a critical failure IMO and should be treated as a panic, which we now do

[DavisVaughan]

For the cases of:

• A single full document change
• 1 or more incremental changes that don't invalidate each other

this is now the only place we recreate the line index