Use LazyLock instead of Lazy

[AaronFeickert]

This PR replaces all uses of Lazy with LazyLock. This removes once_cell as a direct dependency.

[conduition]

Thank you for this! I would love to remove once_cell as a direct dep, but std::sync::LazyLock was only introduced quite recently in the standard library, as of 1.80 (released Aug 2024). Since this crate is a library, we don't always get to control what rust version the downstream users are compiling with, and I'd like to be able to support as many recent toolchains as possible. So for now, once_cell is a necessary evil. Perhaps this PR can be merged in the future but not for now.

As a migration path, i'd consider setting up something with feature flags. Perhaps a feature flag once_cell instead, which is enabled by default (or if k256 is in use, since once_cell is already a dep of k256). If the flag is enabled, the code uses once_cell::sync::Lazy. If the flag is off, the code uses std::sync::LazyLock.

Eventually as LazyLock becomes well established as part of the stdlib, we can someday turn this flag off by default, then remove it completely when we're sure nobody else needs once_cell for backwards compat anymore.

[tarcieri]

We can make a change in the next breaking release of k256 to use std::sync::LazyLock

[AaronFeickert]

@tarcieri: Would this not break no_std?

[tarcieri]

@AaronFeickert it's gated behind a precomputed-tables crate feature in k256

(though I suppose right now it might be possible to use that feature with no_std, at the cost of code size bloat)

[AaronFeickert]

Yeah, right now it doesn't appear to assume std.

[tarcieri]

Right now there's a critical-section feature for k256 which enables once_cell/critical-section which can be used in lieu of std.

Otherwise it's the same functionality, re-exposed via std rather than once_cell.