Introduce VM raw_power_state to deal with various VM state issues

**Update Sept. 15, 2014**

Rebased
Now this PR adds a new field called `raw_power_state` and attempts to keep the original `power_state` field in sync with `raw_power_state`.

------

**Update Sept. 4, 2014**

* Rebased to address @Fryguy's comment about only updating `previous_state` when `raw_power_state` is different from the newly set state.

------

**Update Sept. 4, 2014**

* Rebased to fix some rubocops

------

**Update Sept. 3, 2014**

* Rebased to pull in updated automate tests.
* Added several suggested proposed changes

------

Instead of storing a calculated version of VM power state normalized across the various providers, this PR makes ManageIQ to store the raw power state supplied by the provider.

This allows ManageIQ to react to various states directly instead of having to guess at the correct action.  For instance, Openstack has many different VM states[1] and very specific allowed state transitions.  Previously, ManageIQ attempted to "resume" all "stopped" openstack VMs.  This only works if all "stopped" openstack VMs were actually "suspended".  However, "paused" VMs can only be "unpaused", and "stopped" VMs can only be "started".

Replacing the VM's `power_state` field with the `raw_power_state` field, required several other sweeping changes because templates, cloud and infra VMs all share the same database table.  This requires that several different types of entities know how to either directly handle, or elegantly sidestep, raw power states.

https://bugzilla.redhat.com/show_bug.cgi?id=1115546
https://bugzilla.redhat.com/show_bug.cgi?id=1115557

[1]: http://docs.openstack.org/developer/nova/devref/vmstates.html
Stuff that's "shared" between VmVmware and TemplateVmware can be put in [vmdb/app/models/vm_or_template/vmware_shared.rb](https://github.com/ManageIQ/manageiq/blob/f87d3c71732676aaae56e9768b558f25214a17a4/vmdb/app/models/vm_or_template/vmware_shared.rb).

The EmsRefreshCoreWorker watches raw inventory changes (similar to the broker inventory), and it updates the DB directly for certain high priority columns, thus avoiding having to wait for a refresh.  This includes power state and template changes.

A VM converting into a template is unique to VMware (so far).  The specs for core worker are still accurate as they reflect what to do when different combinations of data are received from VMWare...in some cases the data will be incomplete, and we will get the data on the next pass, so the tests cover all the bases.