elements/div: add an aria_url passthrough

[francois-unity]

Adds .aria_url(...) beside the other aria_* builders, so an element can publish the URL it links to as the AccessKit url property (what a web page exposes for an <a href>).

• AriaProperties gains url: Option<SharedString>.
• write_a11y_info calls node.set_url(...) when it is set, next to the other string properties.
• Window::debug_a11y_tree_json already prints url, so the dump shows it with no change there.

Like the other passthroughs it only describes the element: a click still runs whatever the element handles.

Why: the Unity Hub’s links are gpui divs with Role::Link, and every one of them reports url: null, so neither a screen reader nor an automation client can read the target. The Hub’s design-system Link sets it from its href port once this lands.

How to test

• cargo test -p gpui-ce --lib -- elements::div::tests::test_aria_url_builder_writes_url: the builder writes the node’s url.
• The Unity Hub branch that consumes it reads the URL back out of a real forced tree (Window::a11y_tree) in a headless #[gpui::test].

[marieletellier]

LGTM. aria_url follows the sibling aria_* setters: stored on AriaProperties.url and written with node.set_url(...) in write_a11y_info, and the test asserts node.url(). One commit ahead and zero behind unity/a11y-automation, so fast-forward is possible.

Non-blocking:

1. set_url runs for any role, not just Link. Consistent with the other string props, just noting it.
2. The red CI isn't from this PR: crates/gpui_media/build.rs names bindgen:: at compile time while ac9f1efdcf moved bindgen to a macOS-only build-dependency, so Linux/Windows fail with E0433. build.rs is byte-identical at base and head. The base branch needs its own fix (cfg-gate the bindgen use in build.rs).