Fixed a concurrency issue

Fixed a bug that when several quick requests were occurring, it sometimes happened that more than one mjpegRequest was created. This can be put in evidence with a page making several calls to the same stream:
<pre>
&lt;img src="/index1.jpg"&gt;
&lt;img src="/index1.jpg"&gt;
&lt;img src="/index1.jpg"&gt;
&lt;img src="/index1.jpg"&gt;
...
</pre>
while index1.jpg is served by the mjpeg proxy:
<pre>
app.get('/index1.jpg', 
new MjpegProxy('http://admin:admin@192.168.1.109/cgi/mjpg/mjpg.cgi').proxyRequest);
</pre>
and adding traces each time the mjpegRequest is created.

I noticed this in fact because my own IP camera is not able to serve too many clients (3-4 max in fact), and when displaying several times the same camera images on a page I could get some working correctly, the others being broken.

Looking at the code the selection of whether there is already a client or not is based on the <code>audienceResponses</code> array. This array is populated by <code>_newClient</code>, which is called only once the IP camera has sent an answer (ie <code>mjpegRequest</code> gets a response). If a new request to <code>/index1.jpg</code> is sent before the IP camera had the time to answer, then <code>audienceResponses</code> is not yet populated and we follow the path of the first client again, resulting in the creation of yet another <code>mpjegRequest</code>.

To fix this I have based the detection of the first client on the existence of the <code>mjpegRequest</code>, by making it a member of <code>MjpegProxy</code>. Seems to work better, I can see now a myriad of <code>/index1.jpg</code> on the same page :-)