Doc: use "an SQL" consistently rather than "a SQL"

Similarly to what was done in 04539e7, we standardized on SQL being
pronounced "es-que-ell" rather than "sequel" in our documentation.

Two inconsistencies have crept in during the v15 cycle.  The others
existed before but were missed in 04539e7 due to none of the searches
accounting for "SQL" being wrapped in tags.

As with 04539e7, we don't touch code comments here in order to not
create unnecessary back-patching pain.

Discussion: https://postgr.es/m/CAApHDvpML27UqFXnrYO1MJddsKVMQoiZisPvsAGhKE_tsKXquw%40mail.gmail.com

Author: david-rowley

doc/src/sgml/func.sgml

@@ -19007,7 +19007,7 @@ SELECT JSON_VALUE(jsonb '[1,2]', 'strict $[*]' DEFAULT 1 ON ERROR);
     <listitem>
      <para>
        Defines whether to wrap a returned sequence of <acronym>SQL/JSON</acronym>
-       items into a <acronym>SQL/JSON</acronym> array.
+       items into an <acronym>SQL/JSON</acronym> array.
      </para>
        <variablelist>
         <varlistentry>
@@ -19819,7 +19819,7 @@ JSON_SERIALIZE (
      <title>Description</title>
 
      <para>
-      The <function>JSON_SERIALIZE</function> function transforms a SQL/JSON value
+      The <function>JSON_SERIALIZE</function> function transforms an SQL/JSON value
       into a character or binary string.
      </para>
     </sect5>

doc/src/sgml/ref/select.sgml

@@ -1715,7 +1715,7 @@ SELECT * FROM (SELECT * FROM mytable FOR UPDATE) ss ORDER BY column1;
    <para>
     At the <literal>REPEATABLE READ</literal> or <literal>SERIALIZABLE</literal>
     transaction isolation level this would cause a serialization failure (with
-    a <literal>SQLSTATE</literal> of <literal>'40001'</literal>), so there is
+    an <literal>SQLSTATE</literal> of <literal>'40001'</literal>), so there is
     no possibility of receiving rows out of order under these isolation levels.
    </para>
   </caution>

doc/src/sgml/xfunc.sgml

@@ -445,7 +445,7 @@ $$ LANGUAGE SQL;
 
     <para>
      If the final <literal>SELECT</literal> or <literal>RETURNING</literal>
-     clause in a <acronym>SQL</acronym> function does not return exactly
+     clause in an <acronym>SQL</acronym> function does not return exactly
      the function's declared result
      type, <productname>PostgreSQL</productname> will automatically cast
      the value to the required type, if that is possible with an implicit