[Docs] Update opaque pointers docs (NFC)

Mention automatic enablement of opaque pointers mode that was
recently implemented. Update wording in the transition state,
because it seems like my overly cautious wording has given some
people an incorrect impression of the state of opaque pointer
support in clang.

Author: nikic

llvm/docs/OpaquePointers.rst

@@ -65,7 +65,9 @@ During the transition phase, LLVM can be used in two modes: In typed pointer
 mode (currently still the default) all pointer types have a pointee type and
 opaque pointers cannot be used. In opaque pointers mode, all pointers are
 opaque. The opaque pointer mode can be enabled using ``-opaque-pointers`` in
-LLVM tools like ``opt``, or ``-mllvm -opaque-pointers`` in clang.
+LLVM tools like ``opt``, or ``-mllvm -opaque-pointers`` in clang. Additionally,
+opaque pointer mode is automatically enabled for IR files that use the ``ptr``
+type.
 
 In opaque pointer mode, all typed pointers used in IR, bitcode, or created
 using ``PointerType::get()`` and similar APIs are automatically converted into
@@ -194,12 +196,11 @@ Transition State
 
 As of March 2022 most parts of LLVM support opaque pointers. It is possible
 to build most C and C++ code in opaque pointer mode, both with and without
-optimization, and produce working binaries. However, thes are still some major
+optimization, and produce working binaries. However, thes are still some
 open problems:
 
-* While clang has limited support for opaque pointers (sufficient to compile
-  most C/C++ code on Linux), a major effort will be needed to systematically
-  remove all uses of ``getPointerElementType()`` and the deprecated
+* While clang mostly supports opaque pointers, additional effort will be
+  needed to systematically remove all uses of the deprecated
   ``Address::deprecated()`` constructor.
 
 * We do not yet have a firm strategy for enabling opaque pointers. A large