Control protocol content header: message type

[BenediktBurger]

Main issue: #41 , also related to #29

In #41 we basically came to the conclusion, that we include some message id and the message type in the header.
This issue is about the message type information.

One idea was, to include here the message type (any from the collection in #29).
Another idea is, to include just the format (json, binary, avro...) of the following content frames, in order to decode the correctly.

A third idea is, that this message type information could indicate any of the messages of the control protocol itself (sign in/out, heartbeat, certain error messages) or the format of the content frames (json, binary...).
That would allow to separate more easily between messages meant for the protocol part (heartbeat, sign_in/out, errors...) and RPC calls or other information for the application layer (getting/setting something).

[BenediktBurger]

In #41 (comment) I propose one byte as message type identifier.
That byte identifies the serialization scheme.

We could reserve a certain range for official serialization schemes and another range for user defined schemes.

I propose the following 'message_type' values:

• 0 for not defined / no content
• 1 for json rpc messages (or just json?)