Flesh out ComputeResource entity, test it.

When creating a new "compute resource" entity, a variable set of values must be
provided to the Foreman server. The exact set of values depends on the specified
provider. (e.g. EC2, Rackspace, etc.) Flesh out the ComputeResource entity with
logic necessary for handling this variability in requirements.

Add some API tests for the ComputeResource entity. It is currently *only*
possible to create a libvirt compute resource. All other tests fail for a
variety of reasons. For example:

* Creating a compute resource with a provider of 'Rackspace' causes Foreman to
  throw an HTTP 500 with the message "undefined method `upcase' for
  nil:NilClass".
* Creating a compute resource with a provider of 'GCE' fails because Foreman
  needs more data. However, the types of data needed are not discussed in the
  API docs.
* Creating a compute resource with several other providers causes Foreman to
  return the following error: "getaddrinfo: Name or service not known".
This is a design question that should definitely be pursued. Creating ComputeResource (sub?)classes would simplify the codebase quite a bit. It would eliminate the need for subclassing the `_factory_data` method, it would allow the `read` method to succeed, it would simplify the code in module `test_multiple_paths`, and it makes a bit of logical sense. If this is done, classes such as the following would be created:

* `LibvirtComputeResource`
* `EC2ComputeResource`
* `OpenstackComputeResource`