Document and improve topic message type handling

Comes out of the #691 investigation

We have no mention at all in the documentation on how events coming from topics are handled with regard to the payload type.

Since the switch from annotation driven method resolution we also do not support all "raw" message types that may come from a topic into Akka Serverless.

Some detective work results:

The content type of messages coming in from a topic differs a bit between the two current supported brokers parsing events into "CloudEvents" which always has a content type:
- Google Pub/Sub has a Content-Type attribute in their protocol
- Current Kafka integration looks for a message attribute called ce-datacontenttype
- if an event from either broker does not have that present the type is application/octet-stream
The CloudEvent content-type is then used to turn the event into a protobuf Any to be handed to the user function
- for application/json or application/something+json it is encoded as Any with the type_url json.akkaserverless.com/ + cloud event "type" field (empty if not present)
- for text/plain; charset=utf-8 it is encoded as p.akkaserverless.com/string
- for application/octet-stream it is encoded as p.akkaserverless.com/bytes

We should document how these message types are passed on and or handled by default, per supported broker in the docs.

The old reflection based Java SDK had support for making a parameter or return type have String, protobuf ByteString or a Jackson Annotated type as parameter and the serialization in the SDK handling our internal representations of those types.

We currently have JSON covered by accepting proto Any and provide an explicit conversion. For ByteStrings and raw Strings this feels a bit more clunky but maybe we should make similar utilities for those.

lightbend / kalix-jvm-sdk

Document and improve topic message type handling #715