Review the inheritance architechture

[ajoaoff]

Original issue opened by @diraol at kytos#157.

We have found a big problem regarding the inheritance between versions.

The first plan was to import the classes from a previous version if they haven't changed on the spec between both versions.
So, for example, on v0x01 we have:
v0x01/symmetric/echo_request.py

from pyof.v0x01.common.header import Header, Type
from pyof.v0x01.foundation.base import GenericMessage

class EchoRequest(GenericMessage):
    header = Header(message_type=Type.OFPT_ECHO_REQUEST, length=8)

As the message EchoRequest has the same structure on the version v0x02, we expected to reuse the class from v0x01, so we would have:
v0x02/symmetric/echo_request.py

from pyof.v0x01.symmetric.echo_request import EchoRequest

One of the problems is related to the value passed to the header. So, for example:

>>> from pyof.v0x01.symmetric.echo_request import EchoRequest as ER1
>>> from pyof.v0x02.symmetric.echo_request import EchoRequest as ER2
>>> # Now let's create one message for each class:
>>> msg1 = ER1()
>>> msg2 = ER2()
>>> # Now we want to see the openflow version of each message:
>>> msg1.header.version
UBInt8(1)
>>> msg2.header.version
UBInt8(1)
>>> # As we can see, the version on the message from v0x02 is '1',
>>> # because it is inherited from v0x01.

The same behavior would happen for any attribute that have changed between versions and also for any message that the Type has changed (because a new Type was inserted on the enum before its options).

Another problem is that if we try to create subclasses between versions, the subclass will loose the __ordered__ dict from its superclass, and we need that attribute.

All in all, we need to review how the inheritance for evolutive reuse can be done.

For now, we have decided to fully implement the versions without inheritance between versions.