doc: revise "Breaking Changes" section of Collaborator Guide

Simplify material about TSC approval for breaking changes. Omit
extraneous material explaining that purely additive changes are not
breaking changes.

PR-URL: #25071
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Anto Aravinth <anto.aravinth.cse@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Yuta Hiroto <hello@hiroppy.me>
Reviewed-By: James M Snell <jasnell@gmail.com>

Author: Trott

COLLABORATOR_GUIDE.md

@@ -242,8 +242,8 @@ For undocumented APIs that are public, open a pull request documenting the API.
 
 ### Breaking Changes
 
-Backwards-incompatible changes may land on the master branch at any time after
-sufficient review by Collaborators and approval of at least two TSC members.
+At least two TSC members must approve backward-incompatible changes to the
+master branch.
 
 Examples of breaking changes include:
 
@@ -254,11 +254,6 @@ Examples of breaking changes include:
 * altering expected timing of an event
 * changing the side effects of using a particular API
 
-Purely additive changes (e.g. adding new events to `EventEmitter`
-implementations, adding new arguments to a method in a way that allows
-existing code to continue working without modification, or adding new
-properties to an options argument) are semver-minor changes.
-
 #### Breaking Changes and Deprecations
 
 With a few exceptions outlined below, when backward-incompatible changes to a