Tracking issue for migration to `extern_item_impls`

extern_item_impls provides language support for ergonomically adding getrandom support for targets which do not have a default impl. It also allows to override default getrandom implementations if necessary.

On stabilization of the feature we probably should fully migrate to it by replacing the opt-in backends and the wasm_js crate feature with a number of plug-in implementation crates.

Open questions:

• Should we use externally implementable traits (EITs) instead of externally implementable functions (EIFs)? IIUC EIFs are likely to get stabilized earlier than EITs. Additionally, it looks like the current design of EITs is not compatible with the TryRng trait.
• Security considerations for silently overwriting the default getrandom impls. Ideally, it would be nice if it was impossible to silently override the default impl by just adding a dependency, but the current design of EIFs does not provide a way to protect against it. (previous discussion)
• Should we keep plug-in crates in this repository or move it into a new one?

Start by reading the linked extern_item_impls issue, the externally implementable traits RFC, and the previous discussion in pull request #786. Resolve the EIF/EIT, security, and repository-placement questions before defining the migration scope. Done means the tracking issue has an agreed design and an actionable plan for replacing the opt-in backends and wasm_js feature.