helix-lsp-types: Replace url::Url type with String wrapper

[the-mikedavis]

This replaces the use of the url::Url type with a newtype wrapper around a String. Changing URL type was the original motivation of vendoring/forking the lsp_types crate in #11355. The url crate is based on the WHATWG spec for URLs which conflicts with the spec that LSP requires - RFC3986. This change uses the RFC3986 reserved characters for encoding paths which should fix some issues like #11888. The parsing and interpretation of the URL as a path is then covered by Url::try_from which we use ubiquitously since #11486.

Fixes #11888

[ryanabx]

Hi, correct me if I'm wrong, but RFC3986 defines URIs, why are we using a URL crate for lsp URIs? I think that contributes to issues such as #11334 .

EDIT: maybe this is what this PR fixes?

[the-mikedavis]

Exactly - this PR is working towards removing the url crate as a dependency and representing the URIs from language servers with a regular String instead.

[RoloEdits]

Something I did notice in other work was the conversion of a url to a uri, helix_core::uri::convert_url_to_uri, was very expensive. It ends up calling helix_stdx::path::normalize every time.

Not sure if the changes here will help the need for a conversion, mainly the need to normalize, or if this is entirely unavoidable, but thought I'd share at least. If there is a way to check beforehand that it is normalized, like some kind of fast bloom filter-like check, or modeling a just-in-time conversion for when paths are actually used, rather than an ahead-of-time conversion, this could be a big area of improvement.

This seems to happen most in the publish diagnostics hot path:

helix/helix-term/src/application.rs

Lines 746 to 753 in 3531760

	Notification::PublishDiagnostics(mut params) => {
	let uri = match helix_core::Uri::try_from(params.uri) {
	Ok(uri) => uri,
	Err(err) => {
	log::error!("{err}");
	return;
	}
	};

[the-mikedavis]

I'm not 100% sure we can avoid normalizing paths with this change. I imagine that a language server wouldn't send the same file as two different paths (for example ../dir/../a.txt and ../a.txt) especially since they're usually absolute paths, but maybe it's possible. I would say we can probably try not normalizing at first and add it back if needed.