Refactor ALTER EXTENSION UPDATE to have cleaner multi-step semantics.

This change causes a multi-step update sequence to behave exactly as if the
updates had been commanded one at a time, including updating the "requires"
dependencies afresh at each step.  The initial implementation took the
shortcut of examining only the final target version's "requires" and
changing the catalog entry but once.  But on reflection that's a bad idea,
since it could lead to executing old update scripts under conditions
different than they were designed/tested for.  Better to expend a few extra
cycles and avoid any surprises.

In the same spirit, if a CREATE EXTENSION FROM operation involves applying
a series of update files, it will act as though the CREATE had first been
done using the initial script's target version and then the additional
scripts were invoked with ALTER EXTENSION UPDATE.

I also removed the restriction about not changing encoding in secondary
control files.  The new rule is that a script is assumed to be in whatever
encoding the control file(s) specify for its target version.  Since this
reimplementation causes us to read each intermediate version's control
file, there's no longer any uncertainty about which encoding setting would
get applied.

doc/src/sgml/extend.sgml

@@ -482,10 +482,8 @@
      Secondary control files follow the same format as the primary control
      file.  Any parameters set in a secondary control file override the
      primary control file when installing or updating to that version of
-     the extension.  However, the parameters <varname>directory</>,
-     <varname>default_version</>, and <varname>encoding</> cannot be set in
-     a secondary control file; in particular, the same encoding must be used
-     in all script files associated with the extension.
+     the extension.  However, the parameters <varname>directory</> and
+     <varname>default_version</> cannot be set in a secondary control file.
     </para>
 
     <para>
@@ -689,6 +687,12 @@ SELECT pg_catalog.pg_extension_config_dump('my_config', 'WHERE NOT standard_entr
      to the extension.
     </para>
 
+    <para>
+     If an extension has secondary control files, the control parameters
+     that are used for an update script are those associated with the script's
+     target (new) version.
+    </para>
+
     <para>
      The update mechanism can be used to solve an important special case:
      converting a <quote>loose</> collection of objects into an extension.
@@ -808,7 +812,7 @@ include $(PGXS)
 
      This makefile relies on <acronym>PGXS</acronym>, which is described
      in <xref linkend="extend-pgxs">.  The command <literal>make install</>
-     will then install the control and script files into the correct
+     will install the control and script files into the correct
      directory as reported by <application>pg_config</>.
     </para>