fix: support CONNECT and absolute-form parsing with http >= 1.4.1

[SameerVers3]

Fix HTTP/1 CONNECT and absolute-form request parsing failures when using http crate >= 1.4.1.

Changes:

• Parse non-origin targets as a full Uri in set_raw_path().
• Safely handle empty paths in raw_path() to avoid panics.

Fixes #909

[torinnd]

(with a similar caveat as my issue re: LLM-assistance, plus me not having access to patched_http1)

Thanks for picking this up so quickly — the parse_uri form-detection approach is cleaner than what I'd been carrying locally, and I've adopted it.

One note about the non-UTF-8 path: The lossy branch now routes through parse_uri, so a target that isn't valid UTF-8 and doesn't start with / goes to str::parse::<Uri>() instead of path_and_query(). Since Uri::from_str treats a no-scheme/no-slash string as authority-form rather than a path, I think this changes the behavior the two patched_http1-gated tests rely on:

let raw_path = b"Hello\xF0\x90\x80World"; // invalid UTF-8, no leading slash
let req = RequestHeader::build("GET", &raw_path[..], None).unwrap();
assert_eq!("Hello\u{FFFD}World", req.uri.path_and_query().unwrap());

Previously path_and_query() (with the patched http crate) produced a path-and-query of Hello\u{FFFD}World. With parse_uri, the lossy string "Hello\u{FFFD}World" has no scheme and no leading slash, so parse::<Uri>() should parse it as authority-form (or reject it), making path_and_query() return None and the .unwrap() panic. So I'd expect test_invalid_path and test_override_invalid_path to fail under --features patched_http1.

I can't verify directly since I'm on the stock http. Is patched_http1 exercised in CI here? And is the reinterpretation of non-slash lossy targets as authority-form intended (in which case those two tests probably want updating) or should the lossy branch keep using path_and_query() to preserve the old path-form behavior?