Use more recent Rust features and bump MSRV

[hniksic]

This PR was inspired by the stabilization of std::sync::OnceLock, which allows this crate to omit the dependency to the once_cell external crate. This seems like a benefit that would justify an MSRV bump. And if we're bumping MSRV anyway, then we can also use usize::BITS and simplify the example using scoped threads.

[hniksic]

I've also removed the unreachable module because Rust 1.58 introduced Option::unwrap_unchecked(), Result::unwrap_unchecked(), and Result::unwrap_err_unchecked(). Only Option::unwrap_none_unchecked() is missing, but it was not used by the crate anyway.

If this is undesirable, I'll revert or remove that commit. (The same of course applies to other changes grouped in this PR, which are all in separate commits, and therefore easy to undo.)

[polarathene]

UPDATE: This PR can be closed. I've raised two PRs that carry the remaining relevant changes over:

• chore: Adapt ThreadIdManager for MSRV 1.80 #91
• docs: Switch to thread::scope() for example #92

---

Original message

For reference:

• MSRV-based Cleanup #85 (covers related changes like removing unreachable module + usize::BITS)
• Remove once_cell dependency #76 (alternative that used a static Mutex instead of OnceLock due to MSRV 1.63 vs 1.70)

In #76 there is a mention of BinaryHeap::new() lacking const (now available but raises MSRV to 1.80).

• It seems preferable to revert some of the Remove once_cell dependency #76 changes related to Rust prior to 1.80.0 vs OnceLock / LazyLock (also landed in Rust 1.80.0 and wouldn't require the const fn but otherwise doesn't seem to provide any benefit?).
• UPDATE: I've applied your relevant PR changes here for OnceLock / Rust 1.70 as the first commit of this PR. Then reverted the changes to reflect Remove once_cell dependency #76 but with BinaryHeap:new() related workarounds (prior to Rust 1.80) removed, adding the Rust 1.80 MSRV bump.

The lib.rs docs change in this PR (related to thread::scope improvement with Rust 1.63.0) also doesn't seem to have landed. That seems worthwhile to adopt too (UPDATE: Extracted the docs improvement into a separate PR).

[hniksic]

You're right - closing, as this is indeed covered by other PRs (not all of them merged, though).