Query node: Always use `deserializeMetadata` helper when processing serialized metadata

In some cases in the current query node mappings the metadata is deserialized using `MessageClass.decode()` instead of the `deserializeMetadata` helper:
- https://github.com/Joystream/joystream/blob/master/query-node/mappings/src/membership.ts#L633
- https://github.com/Joystream/joystream/blob/master/query-node/mappings/src/content/channel.ts#L272
- https://github.com/Joystream/joystream/blob/master/query-node/mappings/src/content/channel.ts#L294

This has a few disadvantages:
- The result of `MessageClass.decode()` is an instance of `MessageClass`, not a raw json object
- `MessageClass.decode()` sets the "default" values for all fileds, meaning that even if a string field value is not specified in the encoded message, it is set to `""` in the decoded message (unless converted with `.toObject()`. This makes it very easy to confuse those 2 possible values.
- `MessageClass.decode()` doesn't sanitize strings by removing the dangerous `0x00` character, which can cause the query node to crash when trying to save an entity containing it into the database

Other notable differences between `MessageClass.decode()` and `deserializeMetadata`:
- `MessageClass.decode()` throws error on failure, while `deserializeMetadata` returns `null`
- `deserializeMetadata` takes `Bytes` as serialized input, while `essageClass.decode()` takes `UInt8Array`
- `deserializeMetadata` returns `DecodedMetadataObject` where `T` is the message interface (for example: `IChannelMetadata`), while `MessageClass.decode()` returns the instance of `MessageClass` (where `MessageClass` is, for example: `ChannelMetadata`)