fix(release): avoid embedding dylint-driver source paths

[clabby]

Overview

Detail that was overlooked in #1971: Release builds of cargo-dylint currently compile from the repository checkout, so dylint/build.rs records the sibling driver directory as an absolute path. cargo-binstall users then receive a binary that tries to build dylint_driver from the release runner's /home/runner/work/... checkout, which does not exist outside that job.

Add an explicit DYLINT_DRIVER_FROM_CRATES_IO build-time envvar and set it in the release workflow. Packaged binaries now generate driver crates that depend on dylint_driver by version from crates.io, while local workspace builds continue using the sibling driver path for development.

[smoelius]

@clabby Thanks very much for following up on this.

This is related to #1970, which I opened a couple of weeks ago.

I think I would prefer to not rely on external resources when building a driver. That is, if a driver doesn't currently exist, cargo-dylint could unpack a tar file and build from that. It does something similar for library templates now. I think I could implement that change within the next few days.

Having said that, is the problem you describe a blocker? Are you stuck without this change?

[clabby]

@smoelius Thanks for the quick response.

We're not blocked without this, though the downstream workaround feels a bit messy. The issue can be circumvented by placing the dylint source at the expected DYLINT_DRIVER_MANIFEST_DIR: https://github.com/commonwarexyz/monorepo/pull/3903/changes#r3318545990.

Feel free to take an alternative approach - mainly, what I'd like is for the cargo-dylint binary to behave exactly as it does if built from the source published to crates.io with cargo install cargo-dylint as it does when we use cargo binstall. This PR makes a minimal adjustment to do that by setting DYLINT_DRIVER_MANIFEST_DIR to None when installing from crates.io or the published release artifacts.