Add swap ack channel to server/client

This is a small fix for #29. It adds a channel that is used to count the number of frames the server has processed. If the client gets ahead of the server it will try and read an ack and fail, at this point the client should drop the frame, but it is left up to the API user to do so.

I think there are design improvements, but this solves the issue today.
It's priming the semaphore. Maybe it should be 0, MAX_QUEUED_FRAMES.

2 is pretty much the lowest useful number. If it was 1, the client would queue a frame then have to wait for the frame swap before it could queue another. 2 allows for the server to be processing one frame, and the client to be the next one. Of course the number can be greater then 2, but that can introduce latency.