WIP: Initialize nss explicitly

[jo]

Initialize NSS explicitly, rather than implicitly in NSS-using functions.

⚠️ depends on #6618 ⚠️

To have control over NSS initialization, it must be done explicitly. This pull request removes implicit initialization from the relevant methods and instead checks whether NSS has been initialized and throws an appropriate error if it has not.
Initialization can be done either directly via NSS.

BREAKING CHANGE:
you now need to call nss::ensure_initialized() before any calls to functions which depend on NSS. Watch out for CryptoError(Error(NSS error: NSS has not been initialized)).

Pull Request checklist

• Breaking changes: This PR follows our breaking change policy
  • This PR follows the breaking change policy:
    • This PR has no breaking API changes, or
    • There are corresponding PRs for our consumer applications that resolve the breaking changes and have been approved
• Quality: This PR builds and tests run cleanly
  • Note:
    • For changes that need extra cross-platform testing, consider adding [ci full] to the PR title.
    • If this pull request includes a breaking change, consider cutting a new release after merging.
• Tests: This PR includes thorough tests or an explanation of why it does not
• Changelog: This PR includes a changelog entry in CHANGELOG.md or an explanation of why it does not need one
  • Any breaking changes to Swift or Kotlin binding APIs are noted explicitly
• Dependencies: This PR follows our dependency management guidelines
  • Any new dependencies are accompanied by a summary of the due diligence applied in selecting them.

Branch builds: add [firefox-android: branch-name] to the PR title.

[bendk]

I like this idea in general, the only question for me is how applications should initialize NSS.

[mhammond]

Part of what I don't understand here is what initialization looks like when the "keydb" feature is enabled? Something like logins is eventually going to be used in both contexts, so how would that look? (Sorry if I missed this!)