Map LSP documents by normalised FilePath

[lionel-]

Branched from #1251
Progress towards #1212

See #1250 for more context.

• WorldState now keys documents by normalised FilePath instead of Url. See state.rs. Keying by normalised paths will prevent bugs when matching to paths that don't come from the frontend, e.g. source() paths in user code.

• The original Url sent by the LSP frontend is stored in Document. This is used in communications with the frontend so that we send back exact byte-for-byte Urls, preventing any file matching bugs that could be caused by our internal normalisation of file paths.

Unlike the DAP which has to deal with paths normalised by R, we never resolve symlinks on the LSP side. All matching is done on FilePath based on pure lexical normalisation of paths.

[DavisVaughan]

I really like the idea of this PR! But one blocking comment about Document that I'd like to resolve first

[DavisVaughan]

I feel like these should take path: &FilePath. It would encourage conversion to FilePath at the LSP boundary

[DavisVaughan]

I would like to advocate for the following strategy

pub(crate) documents: HashMap<FilePath, (Url, Document)>,

• Document no longer knows about url. I think this is correct, as you should be able to create a Document without a corresponding url.
• Document no longer has that weird PLACEHOLDER_URL hack, which i really do not like
• insert_document() would be removed since we only .insert() in 1 place in production code, and then in a few tests, so the abstraction doesn't feel worth it

WorldState::get_document() and WorldState::get_document_mut() would then:

• Take a path: FilePath as I mentioned elsewhere
• Abstract over the (Url, Document) enum and just pull out the Document and return it

We would need to go update 2 direct usages of state.document.get() to be state.get_document(), but I think we should do that anyways.

This feels much much better to me, and I looked at all call sites of state.documents. and think it would work quite well

I am quite strongly against PLACEHOLDER_URL, so am going to block this pr until that is resolved

[lionel-]

oops sorry, my fault. I asked Claude to get rid of Option and didn't closely review that one. The placeholder is not only unsightly, it would leak to the user if we made a mistake somewhere.

I did consider hoisting url out of there but it conflicted with existing code IIRC, and I wanted to avoid making too many changes to legacy Ark handlers. Let me take another look.

[lionel-]

oh wait I forgot it's already gone in an ulterior PR!