[1139735] HA upgrade issues with storage cluster schema change
First check-in for the necessary revisions. What makes a storage cluster
schema change difficult is that it requires the entire storage cluster to
be upgraded to the new bits, and to be running, in order to apply the changes.
This runs contrary to our typical upgrade approach which is to shut
everything down and upgrade one install at a time (an install being a
server and/or storage node).  The basic  approach is to now track the
install version for each installed component, and only when evrything has
been upgraded, then do we allow the storage cluster start and then perform
the schema update as a separate upgrade step.
- Add version stamp on rhq_server and rhq_storage_node
- Add db upgrade logic to add fields and init them to the current version
- Add Support to stamp the version on install and upgrades
  - includes updates to jboss modules, rhqctl and installers
  - includes ability to contact RDB from storage installer
- Add --storage-schema and --list-versions coptions to rhqctl upgrade
- Stop server startup unless topology is set to homogenous version, to prevent
  running an environment that is not completely upgraded.

-
[1139735] HA upgrade issues with storage cluster schema change
Commit #2: Remove the server-startup requirement for performing upgrade
--storage-schema. This was bad as the server is already installed/upgraded
at this point. Also, this reduces complexity, improving chances of success.
[1149886] can't start storage node if java installed under somewhere with dir name of bin/java
Fix mazz's goofy use case :)
[1139735] HA upgrade issues with storage cluster schema change
Revert the flawed db-upgrade logic. We can't update all existing rows in
the server and storage_node tables, only the one being upgraded can be set
to the current version. But this is unknown to the upgrade logic.  Instead
create the new column on the fly during the first upgrade that wants to
set it.  Set all rows to an "old" version, and then update only the one row
that reflects the upgrade in progress.  This also has the benefit of
restriction on upgrade ordering.
[1139735] HA upgrade issues with storage cluster schema change
- Fix using the wrong value for storage node address in the version update
- Update logic to complete DDL changes prior to the version stamp, in case
  of failure the DDL changes will still be complete.
- Change version stamp to fail more significantly since it really does
  mess up the install/upgrade, now throws exception as opposed to just
  returning a boolean success flag.
- add some more in-line doco and improve list-versions output
Merge remote-tracking branch 'origin/master' into jshaughn/1139735
Merge branch 'jshaughn/1139735'

Conflicts:
	modules/common/cassandra-installer/src/main/resources/module/main/module.xml