Allow compatibility with recent versions of home

[dtolnay]

According to #28, the reason for using home = ">=0.5, <0.5.11" is to make etcetera compatible with a larger range of compiler versions. However, that is not what that accomplishes. It does not increase the range of compiler versions that etcetera is compatible with. The only thing it accomplishes is making etcetera compatible with a narrower range of home versions. If some crate with a higher MSRV than etcetera wants to use a higher version of home, you have made it impossible for them to do so.

The correct way for applications (binaries) to support installation using an older version of Rust is to use a lockfile (Cargo.lock). It is misguided for libraries to try to provide that effect using < constraints in a Cargo.toml.

[utkarshgupta137]

According to #28, the reason for using home = ">=0.5, <0.5.11" is to make etcetera compatible with a larger range of compiler versions. However, that is not what that accomplishes. It does not increase the range of compiler versions that etcetera is compatible with.

It does make it work with older versions of rust. The 1.70 CI was passing before this PR & now it does not.

The only thing it accomplishes is making etcetera compatible with a narrower range of home versions. If some crate with a higher MSRV than etcetera wants to use a higher version of home, you have made it impossible for them to do so.

Wouldn't the home dependency just get duplicated in Cargo.lock if you want to use it?

The correct way for applications (binaries) to support installation using an older version of Rust is to use a lockfile (Cargo.lock). It is misguided for libraries to try to provide that effect using < constraints in a Cargo.toml.

If someone starts without a Cargo.lock on an older version of rust, then they won't be able to use this library. That was the motivation for this change.

I'll release this change as v0.10 to prevent potential duplication of dependencies, since the plan is to raise the MSRV to 1.86 & use the un-deprecated std::env::home_dir anyway.