Replace SCOPE_REPO with a more ergonomic and less coupled API

[stefanobaghino]

Background

SCOPE_REPO has been deprecated since 5.3.0 (#575). Several replacement approaches have been proposed:

• PR refactor: Drop once_cell in favor of OnceLock/LazyLock #576 proposed replacing the static with a scope_repo() function returning &'static Mutex<ScopeRepository>
• PR Remove external dependency types from the public API #625 tried exposing lock_global_scope_repo() returning MutexGuard<'static, ScopeRepository>

Problem

All proposals so far still expose locking internals (Mutex, MutexGuard), coupling the public API to the current synchronization strategy. Ideally the replacement should be less coupled to the synchronization primitive and more ergonomic for consumers.

Known use case

wastebin needs per-atom string access from a Scope for:

1. Converting scope atoms to CSS class names
2. Checking if a scope's atoms match specific strings (e.g. markdown link detection)

syntect's own html.rs (scope_to_classes, scope_to_selector) uses the same pattern internally.

Ideas discussed

• Scope::atoms() -> Vec<String> — simple but allocates on hot paths used internally by html.rs (#625 comment)
• Closure-based API like Scope::with_atoms(|&[&str]| { ... }) — zero-alloc but ergonomically awkward
• Smarter ClassedHTMLGenerator / hooks into line_tokens_to_classed_spans — would eliminate the need for direct repo access for some users (#625 comment)

Suggestion

I'd suggest adding this to the 6.0.0 milestone since any replacement for SCOPE_REPO will be a breaking change.

References

• Public dependency on once_cell #575 — original deprecation discussion
• refactor: Drop once_cell in favor of OnceLock/LazyLock #576 — scope_repo() proposal by @CosmicHorrorDev
• Remove external dependency types from the public API #625 — lock_global_scope_repo() attempt
• Remove dependencies from public API #512 — remove dependencies from public API (parent effort)

[stefanobaghino]

@matze @keith-hall @CosmicHorrorDev I opened #627 as a draft to suggest a possible approach. It also contains a snippet on how to migrate to the new approach targeted at wastebin.

[CosmicHorrorDev]

this is precisely what i said i dont have the energy for. please don't @ me again in the future