Error check name of image to launch on vCloud Director; comment out softlayer dependancy
Multiple Changes:

1) For YCSB (multiple backends) and Hadoop Virtual Application types, the default behavior
is now to generate a whole new data set for every new load id (i.e., the load generating
process always gets executed against a fresh, newly-generated data set).

2) Improvements on VM ssh keypair manipulation. If a user does not set a default SSH key on
his/her cloud configuration file, then CB will create an ssh keypair on the cloud using
the "cbtool_rsa" pair as source. This should make CB deployments easier/faster.
IMPORTANT: The keypair cbtool_rsa is created by calling the "install" utility.

3) For OpenStack clouds, the parameter OSK_CREDENTIALS can now receive a 4th element,
indicating the path CA bundle file to use in verifying a TLS (https) server certificate.
Therefore, the two possible values for the OSK_CREDENTIALS are:

<user>-<password>-<tenant> (for connections through HTTP)

<user>-<password>-<tenant>-<cacert> (for connections through HTTPS)

4) Improvements and fixes for the API. Now the API calls get_latest_system_data,
get_latest_management_data and get_latest_app_data can be used independently from the
"refresh_vms" API call.
Added automatic keypair creation functionality for the Amazon EC2 cloud adapter.
Merge branch 'master' of https://github.com/bowers/cbtool into bowers-master

Conflicts:
	configs/templates/PUBLIC_dependencies.txt
Merge branch 'bowers-master'
At long last, a functional implementation of the SoftLayer (CCI) Cloud Adapter
for CBTool. At the moment, only vmattach and vmdetach operations are
implemented. The code for vmcapture and vmrunstate operations are
implemented, but not tested.
Re-factored the code that propagated VApp-wide attributes down the VMs.
An example usage would be, in OpenStack, the deployment of new VApps
using tenants/projects different from the one used during the initial cloud
attachment.
Several bugfixes and improvements

1) The checking for passwordless ssh access to the JUMP_HOST (when configured) happens only
after the connection to the cloud (and creation of the appropriate SSH key pair there).
This manner a user can right after the cloud attachment failure, just create a new VM to be
the JUMP_HOST, passing the appropriate public ssh key (cbtool_rsa) by default.

2) Now, by default, logs go to /var/log/cloudbench. Each one of the multiple log files are
prefixed by the USERNAME that launched cloudbench (e.g., cbuser_operations.log), a measure
to allow multiple user to run CB on the same host simultaneously.

3) When an non-existing cloud model is indicated during a cldattach (e.g., "cldattach xyz
TESTCLOUD"), provide an appropriate error message.

4) The default cloud configuration file (i.e., USERNAME_cloud_definitions.txt) can now
reside within a subdirectory inside the configs directory.

5) During the post attachment operations on the VM, a new separate step, before the copy
of the code is rsynced and the post-boot script is run remotely, is executed. In this step
CB just checks to make sure that the ssh is really inject (or already inside) the VM by
remotely running "/bin/true"

6) Fixes an error during the CB startup where the private rsyslog configuration file was
deleted, but the rsyslogd process is still running.

7) The configuration parser now supports nested INCLUDE statements
Multiple changes:

1) Attributes in configuration files now support multi-line values by using the "+=" sign.
For instance an excerpt like the below is now perfectly legal:

...
MY_MULTILINE_ATTRIBUTE = first line
MY_MULTILINE_ATTRIBUTE += second line
MY_MULTILINE_ATTRIBUTE += one more

2) In an effort to make CB more "self-documenting", and the workloads and cloud adpaters
more self-contained, their specific configuration files are being moved. For instance,
gone are the *_application_instances.txt files in configs/templates/ dir. Now, each
Virtual Application type in scripts/<vapp type>/ has a virtual_application.txt file that
contains all the configuration for that particular VApp. The configurations now include a
brief text describing the Virtual Application, shown through the "typeshow <vapptype>"
command.

3) Record the time zone/time difference between VMs and the CB Orchestrator Node (ON).
This information is highly relevant for at least two situations: a) CB ON and VMs just
happen to be actually located in different geographical regions or b) the timezone on the
VMs is not properly set. In CB, the python call (time.time()) is used to create timestamps.
This call is supposedly *defined* to be 1970, 1, 1 in UTC, but in at least one scenario
it could be experimentally verified to be using the localtime. In order to provide the
experimenter with the correct information to allow him to fix any potential errors (due to
timezone shifting) during the production of plots, now the "utc_offset_delta" is provided.
It is provided both as an attribute on the Object Store and as a column in the .csv files
extracted from the metric store.

4) In cb_common.sh, Ganglia (gmond) start/stop operations are split in their own separate
functions, making it easier to restart gmond during the Virtual Application's lifetime.