[clang] [clang][NFC] Refactor `Selector` to use `PointerIntPair` inside (PR #69916)

[Aaron Ballman via cfe-commits]

================
@@ -809,43 +927,42 @@ class Selector {
   enum IdentifierInfoFlag {
     // Empty selector = 0. Note that these enumeration values must
     // correspond to the enumeration values of DeclarationName::StoredNameKind
-    ZeroArg  = 0x01,
-    OneArg   = 0x02,
+    ZeroArg = 0x01,
+    OneArg = 0x02,
     MultiArg = 0x07,
-    ArgFlags = 0x07
   };
 
   /// A pointer to the MultiKeywordSelector or IdentifierInfo. We use the low
-  /// three bits of InfoPtr to store an IdentifierInfoFlag. Note that in any
+  /// three bits of InfoPtr to store an IdentifierInfoFlag, but the highest
+  /// of them is also a discriminator for pointer type. Note that in any
   /// case IdentifierInfo and MultiKeywordSelector are already aligned to
   /// 8 bytes even on 32 bits archs because of DeclarationName.
-  uintptr_t InfoPtr = 0;
+  llvm::PointerIntPair<
+      llvm::PointerUnion<IdentifierInfo *, MultiKeywordSelector *>, 2>
+      InfoPtr;
----------------
AaronBallman wrote:

```suggestion
  llvm::PointerIntPair<
      /// IMPORTANT NOTE: the order of the types in this PointerUnion are
      /// important! The DeclarationName class has bidirectional conversion
      /// to/from Selector through an opaque pointer (void *) which corresponds
      /// to this PointerIntPair. The discriminator bit from the PointerUnion
      /// corresponds to the high bit in the MultiArg enumerator. So while this
      /// PointerIntPair only has two bits for the integer (and we mask off the
      /// high bit in `MultiArg` when it is used), that discrimator bit is
      /// still necessary for the opaque conversion. Do not reorder or add any
      /// arguments to this template without thoroughly understanding how
      /// tightly coupled these classes are.
      llvm::PointerUnion<IdentifierInfo *, MultiKeywordSelector *>, 2>
      InfoPtr;
```

https://github.com/llvm/llvm-project/pull/69916