Remove once_cell dependency

[james7132]

• Tested on all platforms changed
• Added an entry to CHANGELOG.md if knowledge of this change could be valuable to users
• Updated documentation to reflect any user-facing changes, including notes of platform-specific behavior
• Created or updated an example program if it would help users understand this functionality
• Updated feature matrix, if new features were added or implemented

A follow up to #2313. Removes the once_cell dependency, instead using std::sync::OnceLock and a minimal polyfill for std::sync::LazyLock, which may be stablized soon (see rust-lang/rust#121377).

Should it be named LazyLock to match up with the proposed API? I kept it as Lazy for now.

This should not require a bump in MSRV, as OnceLock was stabilized in 1.70, which this crate is using.

[james7132]

Didn't realize the type was in the public interface of the crate. Is this still acceptable as is?

[daxpedda]

I'm not convinced there is sufficient motivation to do this as long as:

• once_cell is one of the most popular crates out there, e.g. our dependencies on Linux use it anyway, so removing it in Winit doesn't actually get rid of the dependency (on Linux).
• Our manual implementation requires unsafe.
• once_cell is a fairly small and well reviewed dependency.

It doesn't affect Web, so its up to the other maintainers.

[daxpedda]

Didn't realize the type was in the public interface of the crate. Is this still acceptable as is?

I assume you mean because of all the CI failures? These things are not actually publicly exposed, they should rather be pub(crate) or pub(super).

[james7132]

Our manual implementation requires unsafe.

This really only is needed if the poly-fill is kept. The actual implementation isn't too bad if we replace every Lazy with a OnceLock.

I assume you mean because of all the CI failures? These things are not actually publicly exposed, they should rather be pub(crate) or pub(super).

Would it be OK to turn those into pub(crate)/pub(super) in this PR?

---

With that said, I'm happy to close this out for now and revisit this when LazyLock gets stabilized, though probably undesirable until the MSRV bump is acceptable.

[madsmtm]

I'd rather go with converting our current use of once_cell to the stable OnceLock, since although it's minor, I don't want to add further unsafe to Winit if it can be avoided.

[notgull]

Agreed with moving away from OnceCell.

[james7132]

I eliminated the unsafe at @notgull's suggestion.

[daxpedda]

Cool!

[notgull]

Thanks!