Remove contentFrame from Client

[jazzz]

Problem

Currently the convo.sendMessage and onNewMessage assume content is formatted as a ContentFrame. As contentFrames are an independent/optional protocol the chat sdk should not require them. ref: #21

Solution

This PR defines a type (Content) as seq[byte] and updates all functions to use it. Clients now expect seq[bytes] as input messages.

Note

• Originally tried to add a generic content type configurable by developers. This would save developers from having to encode and decode their content in every sendMessage and callback. Handling it automatically within the api would improve the developer experience. This caused issues within the type system and will require more work. Pushing this step for now.

[kaichaosun]

The content may introduce broken changes, should we add version to facilitate the upgrades?
Also the app may choose different ways to encode the content, for example, with or without sds.

[jazzz]

The content may introduce broken changes, should we add version to facilitate the upgrades?

Ultimately Applications should be using an interop protocol such as ContentFrames, which handles versioning and type discrimination.

Also the app may choose different ways to encode the content, for example, with or without sds.

1. Whether SDS is used is determined by the conversation type. Developers ought to not even know it exists.
2. The proposed solution does not assume anything about the content. If developers want to wrap their content in another protocol, they are free to do so - It just has to be converted to seq[bytes]

[jazzz]

This PR relaxes the requirements and allows developers to choose any format.

If we think versioning and other features should be mandatory(which I could support) then we should close this PR and leave it as is.

[kaichaosun]

I think versioning is a MUST feature to deliver chat-sdk to 3rd party devs.
Without it, we need a lot of effort to communicate the broken changes, and could be hard to make any major release.

[kaichaosun]

Whether SDS is used is determined by the conversation type. Developers ought to not even know it exists.

SDS brings some level of reliability, but also introduce burden like increased message size. There maybe other solutions that have different tradeoffs. I think it's better to leave space to devs to decide which reliability protocol to use in the future.