feat: add `KeyringController:accountAdded` event + use keyring events in `AccountsController`

[ccharly]

Explanation

Moving the add/remove account/address logic in the KeyringController. This way, we don't need to run a complex logic in the AccountsController everytime a new account gets added.

Part of this logic is now at the KeyringController-level yes, but the logic itself seems simpler, and hopefully, is faster too!

References

N/A

Checklist

• [ ] I've updated the test suite for new or updated code as appropriate
• [ ] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
• [ ] I've communicated my changes to consumers by updating changelogs for packages I've changed
• [ ] I've introduced breaking changes in this PR and have prepared draft pull requests for clients and consumer packages to resolve them

---

[!NOTE] Adds KeyringController:accountAdded/accountRemoved events and updates AccountsController to use these events instead of KeyringController:stateChange, with corresponding tests and changelog updates.

• Keyring Controller:
  • Add and emit KeyringController:accountAdded and KeyringController:accountRemoved events (via overridden update, persistAllKeyrings, and withKeyring).
  • Adjust internals (e.g., make #updateVault async) and add comprehensive event tests.
• Accounts Controller:
  • Subscribe to KeyringController:account{Added,Removed}; implement #handleOnKeyringAccountAdded/#handleOnKeyringAccountRemoved to update internal accounts and publish AccountsController:account{Added,Removed}.
  • Remove reliance on KeyringController:stateChange; update event wiring and tests (including order guarantees for :accountAdded before :selectedAccountChange).
• Changelogs:
  • Document new events and breaking change: AccountsController now requires KeyringController:account{Added,Removed} instead of :stateChange.

^{Written by Cursor Bugbot for commit 5009b0aee6aa8c2822dea3266e5e4dd43657a6f3. This will update automatically on new commits. Configure here.}