Fix lsl_get_channel_bytes to return 0 for cft_string as documented

[myd7349]

The documentation for lsl_get_channel_bytes states that it returns 0 for the string type (cft_string), but in practice this is not the case:

liblsl/include/lsl/streaminfo.h

Lines 174 to 175 in cdf917d

	/// Number of bytes occupied by a channel (0 for string-typed channels).
	extern LIBLSL_C_API int32_t lsl_get_channel_bytes(lsl_streaminfo info);

This patch fixes the issue by returning 0 for the string type.

[myd7349]

The endianness unit test appears to have failed. I will try to fix this issue.

[cboulay]

Thanks @myd7349 — this is correct and worth finishing. Picked it up in #281, which keeps your fix and resolves the tcpserver endian test failure you ran into. That failure turned out to be expected: with channel_bytes() returning 0 for strings, the server stops volunteering an endian conversion and advertises its own host byte order; the string length-prefixes are byte-swapped on the receiving side instead (the data path uses the separate format_sizes[] table, which is unchanged). Updated the test to assert the host byte order accordingly. Full internal + exported test suites pass locally. Will close this once #281 lands.