DOC: fix some keywords arguments documentation

- Typo on "dispatch" keyword arguments.
- Reindent some blocks for better parsing by automated tools.
- "option mysql-check" and "option pgsql-check" arguments were not documented
  as the others.

doc/configuration.txt

@@ -2102,7 +2102,7 @@ dispatch <address>:<port>
   Set a default server address
   May be used in sections :   defaults | frontend | listen | backend
                                  no    |    no    |   yes  |   yes
-  Arguments : none
+  Arguments :
 
     <address> is the IPv4 address of the default server. Alternatively, a
               resolvable hostname is supported, but this name will be resolved
@@ -2721,15 +2721,15 @@ mode { tcp|http|health }
               it is possible to do the same and even better by combining TCP or
               HTTP modes with the "monitor" keyword.
 
-   When doing content switching, it is mandatory that the frontend and the
+  When doing content switching, it is mandatory that the frontend and the
-   backend are in the same mode (generally HTTP), otherwise the configuration
+  backend are in the same mode (generally HTTP), otherwise the configuration
-   will be refused.
+  will be refused.
 
-   Example :
+  Example :
      defaults http_instances
          mode http
 
-   See also : "monitor", "monitor-net"
+  See also : "monitor", "monitor-net"
 
 
 monitor fail { if | unless } <condition>
@@ -3657,8 +3657,8 @@ option mysql-check [ user <username> ]
   May be used in sections :   defaults | frontend | listen | backend
                                  yes   |    no    |   yes  |   yes
   Arguments :
-    user <username> This is the username which will be used when connecting
+    <username> This is the username which will be used when connecting to MySQL
-    to MySQL server.
+               server.
 
   If you specify a username, the check consists of sending two MySQL packet,
   one Client Authentication packet, and one QUIT packet, to correctly close
@@ -3700,8 +3700,8 @@ option pgsql-check [ user <username> ]
   May be used in sections :   defaults | frontend | listen | backend
                                  yes   |    no    |   yes  |   yes
   Arguments :
-    user <username> This is the username which will be used when connecting
+    <username> This is the username which will be used when connecting to
-    to PostgreSQL server.
+               PostgreSQL server.
 
   The check sends a PostgreSQL StartupMessage and waits for either
   Authentication request or ErrorResponse message. It is a basic but useful
@@ -6574,24 +6574,24 @@ unique-id-format <string>
   Arguments :
     <string>   is a log-format string.
 
-    This keyword creates a ID for each request using the custom log format. A
+  This keyword creates a ID for each request using the custom log format. A
-    unique ID is useful to trace a request passing through many components of
+  unique ID is useful to trace a request passing through many components of
-    a complex infrastructure. The newly created ID may also be logged using the
+  a complex infrastructure. The newly created ID may also be logged using the
-    %ID tag the log-format string.
+  %ID tag the log-format string.
 
-    The format should be composed from elements that are guaranteed to be
+  The format should be composed from elements that are guaranteed to be
-    unique when combined together. For instance, if multiple haproxy instances
+  unique when combined together. For instance, if multiple haproxy instances
-    are involved, it might be important to include the node name. It is often
+  are involved, it might be important to include the node name. It is often
-    needed to log the incoming connection's source and destination addresses
+  needed to log the incoming connection's source and destination addresses
-    and ports. Note that since multiple requests may be performed over the same
+  and ports. Note that since multiple requests may be performed over the same
-    connection, including a request counter may help differentiate them.
+  connection, including a request counter may help differentiate them.
-    Similarly, a timestamp may protect against a rollover of the counter.
+  Similarly, a timestamp may protect against a rollover of the counter.
-    Logging the process ID will avoid collisions after a service restart.
+  Logging the process ID will avoid collisions after a service restart.
 
-    It is recommended to use hexadecimal notation for many fields since it
+  It is recommended to use hexadecimal notation for many fields since it
-    makes them more compact and saves space in logs.
+  makes them more compact and saves space in logs.
 
-    Example:
+  Example:
 
         unique-id-format %{+X}o\ %Ci:%Cp_%Fi:%Fp_%Ts_%rt:%pid
 
@@ -6608,10 +6608,10 @@ unique-id-header <name>
   Arguments :
     <name>   is the name of the header.
 
-    Add a unique-id header in the HTTP request sent to the server, using the
+  Add a unique-id header in the HTTP request sent to the server, using the
-    unique-id-format. It can't work if the unique-id-format doesn't exist.
+  unique-id-format. It can't work if the unique-id-format doesn't exist.
 
-    Example:
+  Example:
 
         unique-id-format %{+X}o\ %Ci:%Cp_%Fi:%Fp_%Ts_%rt:%pid
         unique-id-header X-Unique-ID
@@ -6666,7 +6666,7 @@ use-server <server> unless <condition>
   May be used in sections :   defaults | frontend | listen | backend
                                   no   |    no    |   yes  |   yes
   Arguments :
-    <server>   is the name of a valid server in the same backend section.
+    <server>    is the name of a valid server in the same backend section.
 
     <condition> is a condition composed of ACLs, as described in section 7.