[flang][NFC] Document intentional non-support for an extension

[klausler]

Summary

F18 doesn't accept INTEGER operands to the intrinsic LOGICAL operations;
some compilers do. This usage is not portable, and not just because it's
non-conforming -- the bit representations of LOGICAL also vary between
compilers and options. The "MIL-STD" bit intrinsics IAND() & al. have been
avaiable since the late 70's and should be used instead.

[PeteSteinfeld]

Looks good to me!

flang/docs/Extensions.md

 * `Z` prefix on unquoted hexadecimal constants (dangerous)
 * `T` and `F` as abbreviations for `.TRUE.` and `.FALSE.` in DATA (PGI/XLF)
 * Use of host FORMAT labels in internal subprograms (PGI-only feature)
 * ALLOCATE(TYPE(derived)::...) as variant of correct ALLOCATE(derived::...) (PGI only)
 * Defining an explicit interface for a subprogram within itself (PGI only)
 * USE association of a procedure interface within that same procedure's definition
 * NULL() as a structure constructor expression for an ALLOCATABLE component (PGI).
 * Conversion of LOGICAL to INTEGER in expressions.
+* Use of INTEGER data with the intrinsic logical operators `.NOT.`, `.AND.`, `.OR.`,
+  and `.XOR.`.
 * IF (integer expression) THEN ... END IF  (PGI/Intel)
 * Comparsion of LOGICAL with ==/.EQ. rather than .EQV. (also .NEQV.) (PGI/Intel)
 * Procedure pointers in COMMON blocks (PGI/Intel)
 * Underindexing multi-dimensional arrays (e.g., A(1) rather than A(1,1)) (PGI only)
 * Legacy PGI `NCHARACTER` type and `NC` Kanji character literals
 * Using non-integer expressions for array bounds (e.g., REAL A(3.14159)) (PGI/Intel)
 * Mixing INTEGER types as operands to bit intrinsics (e.g., IAND); only two
   compilers support it, and they disagree on sign extension.