build: depend on the shared host crates by path at tip of tree

[elibol]

First PR under #1459.

cuda-oxide depends on the shared host crates by path, but the dependency lines also carried version = "=0.4.0", and check-shared-crate-pin.sh required that exact string in all 234 example workspaces and in the cargo oxide new scaffold. Every host-crate release therefore meant editing cuda-oxide's manifest, every example manifest, the scaffold constant, and the license inventory before the tree was consistent again.

This drops the version requirement from every in-tree path dependency on cuda-bindings, cuda-core, and cuda-async: the three workspace lines and 238 lines across the example manifests. A path dependency with no version always resolves to the sibling directory, so cuda-oxide now tracks the host crates at tip of tree. Nothing in this tree that depends on them (cuda-host, cuda-macros, the examples) is published, so nothing needs the version. Lockfiles are unchanged; the touched example workspaces still pass cargo metadata --locked.

check-shared-crate-pin.sh keeps its name and its CI job but checks the new invariant: the four root crates agree on a version, in-tree manifests name the host crates as path dependencies with no version, and the scaffold's SHARED_HOST_CRATES_VERSION, the one place a crates.io version lives (out-of-tree projects cannot use the git-root paths), equals the root crates' version. It rejects a reintroduced version field; I checked that by hand. Deriving the scaffold constant from the root manifests at build time is the next PR under #1459.

The four host-crate rows in dependency-licenses.csv now record path instead of a version number; check-dependency-licenses.sh compares names only, so they remain valid.

[nihalpasham]

Thanks, @elibol - removing the repeated in-tree version requirements looks good to me.

I'm comfortable treating this build cleanup independently of #1460 and #1461. I'll handle changes to cargo-oxide, including how cargo oxide new gets the runtime version for generated projects.

One small suggestion: please keep the script checking whether a required dependency is missing from Cargo.toml. The updated script misses that case. Cargo would still report the error later, so this doesn’t block the PR.

This partially addresses #1459.