Bug 1074632 - RFE: Manage storage node snapshots (part. 2)

2nd piece of impl above BZ. This patch adds server side capability to manage
snapshots for storage cluster. This basically means that we regularly run
takeSnaphost operation with several parameters - so user can decide whether
to keep all of them, keep last or move older ones to specified location.

6 new private/readonly system settings have been introduced - those settings
can be updated only via Storage admin pages.

User can enable/disable snapshots management of storage cluster and set cron
expression to run management task regulary (additional 4 settings are
basically parameters for takeSnapshot operation introduced within previous
commit for this BZ). When Cluster Setting is saved in UI we re-schedule
takeSnapshot operations on all StorageNode resources in inventory. Also when
new node joins cluster, operation is scheduled on it's resource.

takeSnapshot operation has been added to alert condition for storageNode
management failures, so user is notified when it fails.

Snapshot related code was removed from
StorageNodeManagerBean#runClusterMaintenance()

This PR is not yet ready to be merged
 * need to change log level of several messages
 * need to update Messages_*.properties properly
When ```deployStorageNode``` returns, the new node will not be part of the cluster. The method  only starts a multi-step workflow. I have a digram on the [storage cluster maintenance design doc](https://docs.jboss.org/author/display/RHQ/Storage+Cluster+Maintenance) that shows the steps involved. Let's say we have 2 nodes, node 1 and node2. We decide to deploy node3. Here a brief summary of what will happen,

* node3 is imported into inventory
* node3 is linked to resource
* announce node3 to node1
* announce node3 to node2
* bootstrap node3
* run cluster maintenance on node1 (cleanup only, repair is not necessary)
* run cluster maintenance on node2 (cleanup only, repair is not necessary)
* run cluster maintenance on node3 (cleanup only, repair is not necessary)
    * Note that we do not do to actually do this on node3

To be precise node3 becomes a member of the cluster when it finishes bootstrapping, but we can schedule the snapshots at the end of the workflow.

As I mentioned before, the code involved for executing this and other workflows is getting refactored in a major way. The work is being tracked under [BZ 1120418](https://bugzilla.redhat.com/show_bug.cgi?id=1120418). Because of this, I do not think it is worthwhile to modify the existing deployment workflow code to add in the snapshot scheduling. We can just incorporate it into the new workflow code which is being done in the storage_workflow branch.