core: Replace std with core and alloc, where possible (but on v0.6)

[keks]

This is the same as #411. I rebuilt that on dev-0.6 when I realized that you are not working on master.

---

This tries to pick up where #358 left off, in an effort towards #88. This PR only does obvious things that are easy to review. I will try to look at the others later.

The remaining uses of std are:

• std::collections::HashMap. Unfortunately this is not yet in alloc, and I am not sure when it will be. See Move HashMap to liballoc rust-lang/rust#27242
• std::io and std::fs for obvious reasons.
• std::error. While error_in_core was stabilized in 1.81.0, it looks like the Rust version given in the Cargo.toml is older than that, so I left it for now. Moved to core::error after MSRV was updated to 1.85.

[pdeljanov]

This is good progress! I've bumped the MSRV to 1.85 (Rust 2024 edition) since 0.6 has taken much longer than expected to get out the door. Please make sure to run rustfmt with the nightly toolchain (cargo +nightly fmt) so the diffs are clean and pass the CI.

I won't be committing to no_std in 0.6, but if there are internal-only changes that get us closer I may take those if all the changes look straightforward enough.

Regardless, please feel free to continue pushing no_std forward in this PR branch as it is a popular request and I support the idea even if the majority will need to be pushed to a 0.7.

[keks]

Sounds good! I switched to core::error, formatted and rebased.

For the hashmap it looks like the best way would be to use the hashbrown crate - my understanding is that this is the same as std::collections::HashMap. Let me know if you agree this is the right thing to do and if I should do that switch here or in a separate PR.

Getting rid of std::io will be more work and should probably be done in a separate PR.

[SZenglein]

Hey @pdeljanov, I am interested in this as well.

I won't be committing to no_std in 0.6, but if there are internal-only changes that get us closer I may take those if all the changes look straightforward enough.

Considering these changes essentially only replace std with core, what is keeping you from merging them? I don't think the changes would even affect any user of the library. Is there anything anybody could do to help you with this?

Ignoring this MR is holding up efforts towards no_std that would build on this first step, and I know you have expressed interest in no_std support in the past.