Description of problem:
Grammar mistakes in help of begin, connect, container, locate, put, replace, stats, upgrade commands should be fixed. Wrong words are wrapped in <<wrong word>>
BEGIN COMMAND--------------------------------------------------------------------
SYNOPSIS
    begin [cachename]
    
DESCRIPTION
    Starts a transaction
    
ARGUMENTS
    cachename
        (optional) the name of the cache on which to start the transaction. The currently selected cache will be used if this argument is <<missingThe>> cache must be transactional for
        this command to work
CONNECT COMMAND------------------------------------------------------------------
SYNOPSIS
    connect protocol://[user[:password]@]host][:port][/container[/cache]]
    
DESCRIPTION
    Connects to an Infinispan instance using the specified protocol, host and port and with the supplied credentials.
    
ARGUMENTS
    protocol
        currently only the jmx and the remoting (JMX over JBoss Remoting) protocols are supported. The jmxprotocol should be used to connect to directly over the standard JMX
        protocol, whereas <<theremotingprotocol>> should be used to connect to an Infinispan instance managed within an AS/EAP/JDG-style container.
    user (optional)
        The username to use when connecting if the server requires credentials
    password (optional)
        The password to use when connecting if the server requires credentials. When omitted, the password will be asked for interactively
    host
        the host name or IP address where the Infinispan instance is running
    port
        the port to connect to. For <<theremotingprotocol>> this defaults to 9999
    container (optional)
        the cache container to connect to by default. If unspecified, the first cache container will be selected
    cache (optional)
        the cache to connect to by default. If unspecified, no cache will be selected
CONTAINER COMMAND---------------------------------------------------------------
SYNOPSIS
    container [containername]
    
DESCRIPTION
    Shows the available containers or selects a container to be used as default for CLI operations 
    
ARGUMENTS
    <<cachename>>
        (optional) the name of the container to set as default for the following operations
LOCATE COMMAND------------------------------------------------------------------
SYNOPSIS
    locate [--codec=codec] [cache.]key
    
DESCRIPTION
    Shows the addresses of the owners in the cluster of the entry associated with the specified key. This command <<onlyworks>> for distributed caches
    
ARGUMENTS
    cache
        (optional) the name of the cache to use. If not specified, the currently selected cache will be used. See the cache command
    key the key of the entry for which to show the address--codec=codec option has been specified then the key will be encoded using the specified codec, otherwise the default
        session codec will be used. See <<theencoding>> command for more information
PUT COMMAND---------------------------------------------------------------------
SYNOPSIS
    put [--codec=codec] [--ifabsent] [cache.]key value [expires expiration [maxidle idletime]]
    
DESCRIPTION
    Associates the specified value with the specified key in this cache. If the cache previously contained a mapping for the key, the old value is replaced by the specified value.
    Optionally allows setting of a lifespan and a maximum idle time.
    
ARGUMENTS
    cache
        the name of the cache where the key/value pair will be stored. If omitted uses the currently selected cache (see the <<cachecommand>>)
    key the key which identifies the element in the cache
    value
        the value to store in the cache associated with the keyIf the --codec=<<codecoption>> has been specified then the key and value will be encoded using the specified codec,
        otherwise the default session codec will be used. See <<theencodingcommand>> for more information
    expiration
        an optional expiration timeout (using the time value notation described below)
    idletime
        an optional idle timeout (using the time value notation described below) 
        
DATA TYPES
    The CLI understands the following types:
    string
        strings can either be quoted between single (') or double (") quotes, or left unquoted. In this case it must not contain spaces, punctuation and cannot begin with a number  
        e.g. 'a string', key001 
    int an integer is identified by a sequence of decimal digits, e.g. 256
    long
        a long is identified by a sequence of decimal digits suffixed by 'l', e.g. 1000l
    double
        a double precision number is identified by a floating point number(with optional exponent part) and an optional 'd' suffix, e.g.3.14
    float
        a single precision number is identified by a floating point number(with optional exponent part) and an 'f' suffix, e.g. 10.3f
    boolean
        a boolean is represented either by the keywords true and false
    UUID
        a UUID is represented by its canonical form XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
    JSON
        serialized Java classes can be represented using JSON notation, e.g. {"package.MyClass":{"i":5,"x":null,"b":true}}. Please note that the specified class must be available to
        the CacheManager's class loader.
        
TIME VALUES
    A time value is an integer number followed by time unit suffix: days (d), hours (h), minutes (m), seconds (s), milliseconds (ms)
REPLACE COMMAND-----------------------------------------------------------------
See put command above
UPGRADE COMMAND-----------------------------------------------------------------
SYNOPSIS
    upgrade [--dumpkeys | --synchronize=migrator | --disconnectsource=migrator] [cachename | --all]
    
DESCRIPTION
    This command performs operations used during the rolling upgrade procedure.
    
ARGUMENTS
    --dumpkeys
        Performs the dump of all the keys in the cache to a known entry. It must be performed on the "source" cluster so that the "target" cluster can fetch the entire keyset
        efficiently to complete the synchronization operation
    --synchronize=migrator
        Performs the synchronization of all data from the "source" cluster to the "target" cluster using the specified migrator. It must be performed on the "target" cluster after
        the --dumpkeys operation has been performed on the "source" cluster. The only migrator currently available is hotrod which migrates entries between caches exposed via the
        HotRod remoting protocol.
    --disconnectsource=migrator
        Disconnects the "target" cluster from the "source" cluster. This is performed in a migrator-specific way. After this operation has been performed the "source" cluster can be
        switched off
    --all
        Specifies that the requested operation should be performed on all caches in the currently selected container 
    cachename
        (optional) the name of the cache on which to invoke the specified upgrade command. If unspecified, the currently selected cache will be used. See also the --all switch above 
        
USAGE
    In order to perform a rolling upgrade of a HotRod cluster, the following steps must be taken
    1. Configure and start a new cluster with a RemoteCacheStore pointing to the old cluster and the
        hotRodWrapping flag enabled
    2. Configure all clients so that they will connect to the new cluster
<<some space alignment needed here on 3. >>
        3. Invoke the
        upgrade --dumpkeys command on the old cluster for all of the caches that need to be migrated
    4. Invoke the
        upgrade --synchronize=hotrod command on the new cluster to ensure that all data is migrated from the old cluster to the new one
    5. Invoke the
        upgrade --disconnectsource=hotrod command on the new cluster to disable the RemoteCacheStore used to migrate the data
    6. Switch off the old cluster