CH12: Remove "other ways to soft fork"

This short subsection described segwit's use of always-true
scriptPubKeys as special.  It didn't mention the similar mechanism used
for BIP16 P2SH.  It also doesn't mention block-focused changes like
BIP32 and BIP34, or non-script changes like BIP66, BIP68, and BIP113.
I think it should either be greatly expanded or removed, and removing is
easier right now.  :-)

ch10.asciidoc

@@ -2392,28 +2392,6 @@ is a soft fork because a transaction that is valid under BIP65 is also
 valid on any client that is not implementing (ignorant of) BIP65. To
 the old clients, the script contains an NOP code, which is ignored.
 
-===== Other ways to soft fork upgrade
-
-The reinterpretation of NOP opcodes was both planned for and an obvious
-mechanism for consensus upgrades. Recently, however, another soft fork
-mechanism was introduced that does not rely on NOP opcodes for a very
-specific type of consensus change. This is examined in more detail in
-<<segwit>>. Segwit is an architectural change to the structure of a
-transaction, which moves the unlocking script (witness) from inside the
-transaction to an external data structure (segregating it). Segwit was
-initially envisioned as a hard fork upgrade, as it modified a
-fundamental structure (transaction). In November 2015, a developer
-working on Bitcoin Core proposed a mechanism by which segwit could be
-introduced as a soft fork. The mechanism used for this is a modification
-of the locking script of UTXO created under segwit rules, such that
-unmodified clients see the locking script as redeemable with any
-unlocking script whatsoever. As a result, segwit can be introduced
-without requiring every node to upgrade or split from the chain: a soft
-fork.
-
-It is likely that there are other, yet to be discovered, mechanisms by
-which upgrades can be made in a forward-compatible way as a soft fork.
-
 ==== Criticisms of Soft Forks
 
 ((("forks", "changing consensus rules", "soft fork drawbacks")))((("soft