Add orm.EntityCreateMixin, drop factory module

The methods provided by this mixin work together to create an entity. A
typical tree of method calls looks like this:

    create
    └── create_json
        └── create_raw
            ├── create_missing
            └── create_payload

Only `create_raw` communicates with the server.

Drop module `robottelo.factory` and `tests.robottelo.test_factory`. As a result
of this change, the `Factory` and `EntityFactoryMixin` classes are gone. Several
other methods are also no longer available on inhering classes:

* attributes
* build
* _factory_data
* _factory_path

Rewrite significant amounts of code to deal with this change. Modules
`tests.foreman.api.test_multiple_paths` and `robottelo.entities` require the
most significant changes, but others are affected too.

Change the `Meta.api_names` attribute that exists on many classes in module
`robottelo.entities` from a tuple of tuples to a dict. This is more intuitive,
class `EntityReadMixin` is hardly affected, and class `EntityCreateMixin` is
much simpler.

Deprecated methods are not used:

    $ git grep 'attributes()\|build()\|_factory_path\|_factory_data'

The affected tests succeed:

    $ nosetests tests/foreman/api/test_{organization,system,multiple_paths}.py
    ...............................SSS.........................SS.S....SSS..S....SS...S...........S....S................................................S...........S....S........................................................SSSS.SSSSSS..S.SSSSSSS..SSSSSSSSSSSSSSSSSSSSSSSSSSSSS
    ----------------------------------------------------------------------
    Ran 275 tests in 306.406s

    OK (SKIP=65)

This change has several positive effects:

* Class `EntityCreateMixin` is much easier to comprehend than class `Factory`
  and derived code. The latter is complicated enough that even the original
  author (hi!) has trouble understanding it at times. This means that the bus
  factor can increase.
* `EntityCreateMixin` is more capable than class `Factory` and derived code. For
  example:

  * `create_raw` allows access to the response objects received from the
    server, and therefore information like status codes and the response message
    as a byte stream. The latter is expecially useful when no JSON response can
    be decoded.
  * `create_payload` allows one to see exactly what will be submitted to the
    server. This is great for inspection purposes, and it also allows subclasses
    to easily manipulate the form of that data.

* Much test code which calls `client.post` can call `create_raw` instead, which
  is more compact.
There is no right but a better approach for a given time because each project have its own life and get improved every day.

In the beginning using the tuple seemed better, but now the dict is much better :smile: