doc: Standardize use of dashes in references to CRC and SHA.

Presently, we inconsistently use dashes in references to these
algorithms (e.g., CRC32C versus CRC-32C).  Some popular web sources
appear to prefer dashes, and with this commit, we will, too.

Reviewed-by: Robert Haas
Discussion: https://postgr.es/m/ZrUFpLP-w2zTAHqq%40nathan

doc/src/sgml/backup-manifest.sgml

@@ -87,10 +87,10 @@
     <listitem>
      <para>
       This key is always present on the last line of the backup manifest file.
-      The associated value is a SHA256 checksum of all the preceding lines.
+      The associated value is a SHA-256 checksum of all the preceding lines.
       We use a fixed checksum method here to make it possible for clients
-      to do incremental parsing of the manifest. While a SHA256 checksum
-      is significantly more expensive than a CRC32C checksum, the manifest
+      to do incremental parsing of the manifest. While a SHA-256 checksum
+      is significantly more expensive than a CRC-32C checksum, the manifest
       should normally be small enough that the extra computation won't matter
       very much.
      </para>

doc/src/sgml/pgcrypto.sgml

@@ -106,7 +106,7 @@ hmac(data bytea, key bytea, type text) returns bytea
 
   <para>
    The algorithms in <function>crypt()</function> differ from the usual
-   MD5 or SHA1 hashing algorithms in the following respects:
+   MD5 or SHA-1 hashing algorithms in the following respects:
   </para>
 
   <orderedlist>
@@ -525,7 +525,7 @@ gen_salt(type text [, iter_count integer ]) returns text
    </listitem>
    <listitem>
     <para>
-     A SHA1 hash of the random prefix and data is appended.
+     A SHA-1 hash of the random prefix and data is appended.
     </para>
    </listitem>
    <listitem>

doc/src/sgml/ref/pg_basebackup.sgml

@@ -687,7 +687,7 @@ PostgreSQL documentation
        <para>
         Using a SHA hash function provides a cryptographically secure digest
         of each file for users who wish to verify that the backup has not been
-        tampered with, while the CRC32C algorithm provides a checksum that is
+        tampered with, while the CRC-32C algorithm provides a checksum that is
         much faster to calculate; it is good at catching errors due to accidental
         changes but is not resistant to malicious modifications.  Note that, to
         be useful against an adversary who has access to the backup, the backup