Clarify terminology standalone backend vs. single-user mode

Most of the documentation uses "single-user mode", so use that in the
code as well.  Adjust the documentation to match the new error message
wording.  Also add a documentation index entry for "single-user mode".

Based-on-patch-by: Jeff Janes <jeff.janes@gmail.com>

doc/src/sgml/maintenance.sgml

@@ -581,17 +581,17 @@ HINT:  To avoid a database shutdown, execute a database-wide VACUUM in "mydb".
 
 <programlisting>
 ERROR:  database is not accepting commands to avoid wraparound data loss in database "mydb"
-HINT:  Stop the postmaster and use a standalone backend to VACUUM in "mydb".
+HINT:  Stop the postmaster and vacuum that database in single-user mode.
 </programlisting>
 
     The 1-million-transaction safety margin exists to let the
     administrator recover without data loss, by manually executing the
     required <command>VACUUM</> commands.  However, since the system will not
     execute commands once it has gone into the safety shutdown mode,
-    the only way to do this is to stop the server and use a single-user
-    backend to execute <command>VACUUM</>.  The shutdown mode is not enforced
-    by a single-user backend.  See the <xref linkend="app-postgres"> reference
-    page for details about using a single-user backend.
+    the only way to do this is to stop the server and start the server in single-user
+    mode to execute <command>VACUUM</>.  The shutdown mode is not enforced
+    in single-user mode.  See the <xref linkend="app-postgres"> reference
+    page for details about using single-user mode.
    </para>
 
   </sect2>

doc/src/sgml/ref/postgres-ref.sgml

@@ -529,6 +529,10 @@ PostgreSQL documentation
    <refsect2>
     <title>Options for Single-User Mode</title>
 
+    <indexterm>
+     <primary>single-user mode</primary>
+    </indexterm>
+
     <para>
      The following options only apply to the single-user mode.
     </para>

src/backend/access/transam/varsup.c

@@ -73,7 +73,7 @@ GetNewTransactionId(bool isSubXact)
 	 * If we're past xidVacLimit, start trying to force autovacuum cycles.
 	 * If we're past xidWarnLimit, start issuing warnings.
 	 * If we're past xidStopLimit, refuse to execute transactions, unless
-	 * we are running in a standalone backend (which gives an escape hatch
+	 * we are running in single-user mode (which gives an escape hatch
 	 * to the DBA who somehow got past the earlier defenses).
 	 *
 	 * Note that this coding also appears in GetNewMultiXactId.
@@ -114,14 +114,14 @@ GetNewTransactionId(bool isSubXact)
 						(errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
 						 errmsg("database is not accepting commands to avoid wraparound data loss in database \"%s\"",
 								oldest_datname),
-						 errhint("Stop the postmaster and use a standalone backend to vacuum that database.\n"
+						 errhint("Stop the postmaster and vacuum that database in single-user mode.\n"
 								 "You might also need to commit or roll back old prepared transactions.")));
 			else
 				ereport(ERROR,
 						(errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
 						 errmsg("database is not accepting commands to avoid wraparound data loss in database with OID %u",
 								oldest_datoid),
-						 errhint("Stop the postmaster and use a standalone backend to vacuum that database.\n"
+						 errhint("Stop the postmaster and vacuum that database in single-user mode.\n"
 								 "You might also need to commit or roll back old prepared transactions.")));
 		}
 		else if (TransactionIdFollowsOrEquals(xid, xidWarnLimit))