Separate eof callback in Payload.t clashes with FIN bit style

Frame payloads are read in chunks using `Payload.t`, and the end of frame is signalled with an `on_eof` callback *after* the last chunk is provided with the `on_read` callback:

https://github.com/anmonteiro/websocketaf/blob/248a2cb0dcffa51996c3ad7643577dce75d67454/lib/websocketaf.mli#L8-L12

However, the `FIN` bit is provided *with* the last frame (not *after*):

https://github.com/anmonteiro/websocketaf/blob/248a2cb0dcffa51996c3ad7643577dce75d67454/lib/websocketaf.mli#L230

In Dream, I chose to treat chunks as the frames in my reader, i.e. if a frame is split into multiple chunks during reading, I just emit those chunks, and report `FIN` with the last chunk of the last frame. However, because the `on_eof` callback gets called *after* that last chunk, I have to [cache](https://github.com/aantron/dream/blob/b5c0e774501911196f201fde107b4b672ba3bc3e/src/http/http.ml#L99-L117) each chunk until the reader knows whether the next callback turns out to be `on_eof` or not.

I chose to have the reader report `FIN` with the last chunk, rather than also with a separate `on_eof` callback, for symmetry with WebSocket writing, because the WebSocket protocol requires `FIN` to be provided with the last frame. Providing it after the last frame would similarly require a WebSocket writer to cache each chunk until it knew whether `FIN` was set by a next `eof` call or not.

I think it would be better to remain consistent with the WebSocket protocol and writers, and have `schedule_read` somehow report the last chunk in the `on_read` callback.

I think it's possible to get a similar effect by tracking the total number of bytes read and comparing to the length from the frame header, but I am not sure how trustworthy that is.