Waltham-receiver: Check the behavior of handling rendering request

Close for HH RC1

Now waltham-receiver incl this change is under review: 
Anyway it's redundant so let me close it.

This bug was found in Waltham-receiver which ADIT has not yet upstreamed to AGL. I apologize that I mistakenly created this ticket.
We'll Upstream waltham-renderer including the fix for this issue by the end of this month.

FYI:
Summary of this bug:
If new frame comes before the current rendering processing goes wait, callback processing emits signal and becomes wait.
This means, if new rendering request comes during surface rendering, it goes deadlock.

Change applied:

• Change the design to use Circular array to maintain the gst buffer received from the transmitter.

• We have two variable namely front and rear.

• buffer coming from transmitter triggers appsink callback and are inserted in to circular array(ring buffer) and rear is incremented every time a buffer inserted.

• main function keeps checking whether the queue has any filled with buffer and if buffer are present it renders the image and decrement the front.

• Currently the max sample in the queue is set to 60. It can be configured by changing the macro #define MAX_SAMPLE 60

• This Approach removes the complexity of using mutex lock, condition signaling.