test to create a filter
test to create a filter
Slightly clean up and flesh out an API test
resolved conflicts
Make System().create() work

When `System().create()` is called, it fails with the following error messages:

* `u'facts': [u"can't be blank"]`
* `u'cp_type': [u'is not included in the list']`

Update the `System` entity so that these errors are no longer encountered. To
fix these errors, the make the following fixes:

* By default, set `System.facts` to `{'uname.machine': 'unknown'}`.
* By default, set `System.type_` to 'system'.

Also:

* Add attribute `System.uuid` and override the default implementation of
  `System.path` to use a system's UUID instead of ID for identification.
* Alphabetically reorder `System`'s attributes.
* Remove the set of comments from `System`. These comments can be dangerous, as
  they can become outdated relative to the official API docs. (Note that this
  was the case with the `System.type` attribute.)
* Rename `System.system_type` to `System.type`. This is done so that the
  `System` entity can map as closely as possible to what the server is
  expecting.
Test the System entity

Add the `System` entity to module `tests.foreman.api.test_multiple_paths`.
Systems cannot be fully tested by this module, though, as the module expects
each entity to be uniquely identified by an ID, and a system is uniquely
identified by a UUID. Add module `tests.foreman.api.test_system_v2`, which makes
use of system UUIDs in its tests. For more details, see the docstring in module
`test_system_v2`.

Test method `System.path`.
Merge pull request #1218 from Ichimonji10/system-entity

Make System().create() work
tests on roles and permissions
Merge pull request #1222 from sghai/perm

Roles and permissions tests using filters
Add feature to run UI in headless mode

By configuring virtual_display=1 in properties file, robottelo will use
a virtual display to run UI tests using PyVirtualDisplay package and
Xvfb.
Merge pull request #1223 from elyezer/virtual-display

Add feature to run UI in headless mode
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 All tests for the
ComputeResource currently fail. These 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".

These issues should be tackled by someone who knows more about compute
resources.