Minor fixes and QoL improvements

[jaybosamiya]

1. Bring set-up-rust.sh into sync with the README by making it executable (the README expects it to be executable)
2. Correctly account for symlinks
   1. if the rust/ directory is being pulled in as a symlink---useful if you're holding on to multiple copies of verus during development, where you want to share the main rust installation
   2. if the main verus repo itself is inside a symlinked folder
3. Reintroduce Cargo.lock. See "rationale for cargo.lock" below.

Hopefully all these changes are basically uncontroversial and since they're all minor enough, I rolled them all up into a single PR.

Rationale for (re)introducing Cargo.lock

Cargo.lock was originally .gitignored in d4ded8f

This was in 2021, as a "for now" measure, presumably since things were changing rapidly, and maintaining a lockfile was more trouble than was worth.

However, we've moved quite a bit from there, and our Cargo.tomls have been quite stable, changing very rarely. Thus it seems reasonable to rethink this decision to .gitignore the lock file. Maintaining the Cargo.lock would help future-proof things.

Maintaining a Cargo.lock file is considered good standard practice for bin crates (which is what Verus is): https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries

The purpose of a Cargo.lock lockfile is to describe the state of the world at the time of a successful build. Cargo uses the lockfile to provide deterministic builds on different times and different systems, by ensuring that the exact same dependencies and versions are used as when the Cargo.lock file was originally generated.

This property is most desirable from applications and packages which are at the very end of the dependency chain (binaries). As a result, it is recommended that all binaries check in their Cargo.lock.

Also, just as a quick point of comparison, rustc does maintain a Cargo.lock file too: https://github.com/rust-lang/rust/blob/master/Cargo.lock

[utaal]

Changes to the scripts look good to me. Thank you!

I am however not in favor of adding a Cargo.lock: we have fairly specific versions in the Cargo.toml which we haven't updated in months (which doesn't bode well for us remembering to update the Cargo.lock); I don't see much value in locking the deps when we don't have wildcard matches on the version numbers, and we never had a build failure due to a dependency mismatch. I think it's still more trouble than it's worth at this stage (we're about to make fairly significant changes to move off of the rustc fork).

[jaybosamiya]

Thanks for looking over the PR!

Due to how dependencies in Cargo.toml are handled, even something that doesn't appear to be a wildcard version, for example:

num-bigint = "0.4.3"

is actually a wildcard. It is a restricted wildcard, no doubt (in this case, it means >= 0.4.3, < 0.5.0), but still is a wildcard, and thus Cargo.lock still has value even here. The lack of dependency failures right now can probably be attributed more to our dependencies actually following semver well.

Anyways, no need to block the other changes on this, so I'll remove the Cargo.lock changes, so that the branch can be merged. We can revisit the Cargo.lock decision in the future (I'll set up a discussion issue to track this for whenever we get around to it -- #368).