[1139735, 1157480] More upgrade use cases that didn't work.
[1139735] An upgrade with a number of storage nodes > than our replication
factor (>= 4) could fail because our check for the storage cluster
version can fail if the auth info or version info are not replicated
to the currently running SNs.  To avoid this, for ugrades we now push
all storage cluster interaction to the post-upgrade step (i.e.
rhqctl --storage-schema).  This includes the schema creation for a new,
remote storage cluster.

[1157480] An upgrade of standalone storage node can fail because those
installs may not have set proper DB props in rhq-server.properties.  It
wasn't required in the past but it is now.  In the code we now make sure
the properties are copied forward on upgrade. But there is also doco needed
here because prior to upgrade from an earlier version, using standalone
SNs, the old rhq-server.properties files will need to be updated.

Also, update the --list-versions report to better reflect that it may need
all SNs to be running to perform the storage schema version check.