Stabilization: Use LazyLock API instead of helper methods

[Qkessler]

What should be done?

After this PR (#33), we use the OnceLock API to create static variables shared by the program. OnceLock is the less-ergonomic brother of the cooler LazyLock, which is not yet stable (issue tracker).

Using OnceLock, we create helper methods (see buffers(), features() or interned_symbols() on the PR):

pub(crate) fn features() -> &'static Mutex<HashSet<Symbol<'static>>> {
    FEATURES.get_or_init(|| Mutex::new(HashSet::default()))
}

Once LazyLock stabilizes, we can migrate the code from OnceLock to LazyLock, and benefit from some code removals: we'll remove the helper methods created to access them (using get_or_init). The code above would turn into something like:

/// Rust translation of the `features` variable: A list of symbols are the features
/// of the executing Emacs. Used by [`featurep`] and [`require`], altered by [`provide`].
pub(crate) static FEATURES: LazyLock<Mutex<HashSet<Symbol<'static>>>> =
    LazyLock::new(|| Mutex::new(HashSet::default()));

Why this task should be completed?

It reduces the need of using helper functions, which just saves a handful lines of code. OnceLock will work the same way with the same guarantees, paired with the helper functions.

Acceptance Criteria

• You have verified the code can run on the beta channel: rustup default beta
• You have made sure the stabilization issue is closed and merged: issue tracker.
• You have tested the integration works with cargo build --release, cargo t, cargo clippy.

Who are the POCs or Stakeholders?

• @CeleritasCelery , @Qkessler