fix epic_stream_read API

Epicardium sensor stream use the FreRTOS Queue-API, which transfers fixed size blobs of bytes. To work correctly, a client of this API (like pycardium) must interpret the bytes received from the queue the same way as the sender. Unfortunately, there is no way to statically enforce this, so the existing code used a simple heuristic to detect some misuses of the API: it checks that the size of the buffer passed by the client to epic_stream_read is a whole multiple of the sensor data size. But this is prone to errors: if the client passes a buffer that can hold thirty data packets of size eight, but accidentally specifies a queue with a packet size of six, the API may read up to fourty data packets, and if the client doesn't check for the possibillity that the API returns a number of read packets that is larger than the maximum requested (which none of the (two) existing clients did), it will happily read past the end of the buffer, triggering undefined behavior.

The modified API does instead force the client to pass the size of the data packets and the maximum number of packets to read, and so makes sure that the API will never read more packets than requested. If the client still happens to specify a wrong queue with the right packet size it will of course still get garbage data.