Bump MSRV

[therealfrauholle]

I want to discuss bumping the current MSRV of 1.43. In my latest attempt to add support for the defmt framework (see #386) I could not use defmt, since it requires at least rust 1.56.

Besides helping me solve my problem, I also saw that bumping the MSRV could solve some more problems, e.g. #216 or #82; and probably more.

Even thought it may break builds for others, most major crates do not treat bumping the MSRV as a breaking change. I checked a discussion crossbeam-rs/crossbeam#503 for reference, there are some very interesting and valuable comments regarding bumping the MSRV there.

@iliekturtles can probably judge better how dependents use uom (and what MSRV they need); but I checked some of the dependents through crates.io and cargo msrv, these are the three most downloaded crates that use uom:

• battery depends on uom:0.30.0; does not build below 1.46; last commit 2 years ago; mainly used in the actively maintained bottom crate which does not build below 1.61
• heim-common depends on uom:0.30.0; does not build below 1.56; last commit 1.5 years ago.
• starship-battery depends on uom:0.30.0; does not build below 1.40; part of the actively maintained starship crate which specifies a MSRV of at least 1.60.

These are the three most downloaded crates that use the most recent version:

• sgp4-rs depends on uom:0.33.0; does not build below 1.56
• libmedium depends on uom:0.33.0; does not build below 1.56
• rtforth depends on uom:0.33.0; does not build below 1.56; last changes 23 days ago.

So by looking at this I think it is reasonable to assume bumping the version to 1.56 will not be a deal for most people. Speaking more generally, I suggest to make a MSRV policy similar as discussed in crossbeam-rs/crossbeam#503, that gives users a guarantee that uom will never have a MSRV newer than 6 months, but uom contributors have the chance to bump the version somewhat regularly to make use of the newest stable features. What is your opinion @iliekturtles?

[therealfrauholle]

Possible duplicate of #239 I just saw.

[iliekturtles]

Copied from #216 before I caught up with this issue:

I'm interested in bumping the MSRV but I'm a bit hesitant to go all the way to 1.60 when the work-arounds to resolve #216 issue aren't too painful and allow for an older MSRV. I don't have a specific policy about when to update the MSRV and what version to jump to so I'm interested in hearing thoughts about going all the way to 1.60.

---

After (mostly) reading the Crossbeam thread and now that I've seen the defmt PR I'm more inclined to jump to 1.60. It is ~6 months old if the defmt feature gets accepted alongside serde why deal with feature name work-arounds for both.

Whatever MSRV we jump to I would like to release the current master as v0.34.0 now. Finally get @crystal-growth's remaining quantity/unit PRs merged into a branch to be released as v0.34.1 and allow for changes that need the new MSRV to start being merged into master.

[iliekturtles]

https://github.com/iliekturtles/uom/actions/runs/5365520967/jobs/9734386156?pr=421#step:4:53

log has a MSRV of 1.60.0. I'm looking at this now to fix all the bitrot with the github action failures.