doc: remove redundant LTS/Current information in Collaborator Guide

Remove bullet points about how breaking changes are handled in Current
and LTS branches.

* This information is covered in
  https://github.com/nodejs/Release#release-plan.
* Having it here and in the above link means that the two may get out of
  sync, resulting in confusion.
* The above link appears later in the doc in the LTS section.
* Most Collaborators should not land *anything* in LTS branches and will
  almost never have a reason to land things into Current branches. They
  land stuff on the master branch. Adding this material here is
  confusing because it implies that Collaborators do land stuff on those
  branches. Save talk about those branches and how they're managed for
  later in the LTS section where it can be made clear that most
  Collaborators should not be landing code there anyway.

PR-URL: nodejs#25842
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>

COLLABORATOR_GUIDE.md

@@ -278,14 +278,6 @@ providing a Public API in such cases.
 
 #### When Breaking Changes Actually Break Things
 
-* Breaking changes should *never* land in Current or LTS except when:
-  * Resolving critical security issues.
-  * Fixing a critical bug (e.g. fixing a memory leak) requires a breaking
-    change.
-* If a breaking commit does accidentally land in a Current or LTS branch, an
-  attempt to fix the issue will be made before the next release; If no fix is
-  provided then the commit will be reverted.
-
 When any changes are landed on the master branch and it is determined that the
 changes *do* break existing code, a decision may be made to revert those
 changes either temporarily or permanently. However, the decision to revert or