Add WebRTC's FEC processing to ExternalOutput

WebRTC does FEC processing to reduce corruption in video due to packet loss.  Let's implement that!  I stripped out just the FEC portion of WebRTC and incorporated that.  One important note: WebRTC has its own endianness detection that's implemented in rtp_utility.cc; it is very important to get that right or you're find yourself exploding inside std::list in a really confusing way.  I think the routine as-is will work for licode across the board, but we probably want to double-check that.

Recording should be unaffected; the only consequence of this change should be "less corruption" in output video.  Corruption is still possible until ExternalOutput starts receiving retransmitted packets coming in on the Rtx SSRC channel.
Remove err.txt, accidentally checked in.
No need for a recursive mutex.
Remove unused GMainLoop variable.
Let's stop trying to take locks in destructors.  It's a bad pattern and it implies some other threading problem that needs to be resolved.  The only thing it'll result in is deadlocks.
Remove the queue packet call in the destructor; that call was doing nothing previously because the state had been set to FINISHED, and no packet is queued in that state.

Change the code so we set running_ to false and ICE_FINISHED, and then signal the condition.  In getPacket(), have code that checks the state and returns appropriately.  This allows the Dtls thread to bail.
Few more changes:

1. In NiceConnection, remove agentMutex_; I don't see a good reason to protect this object in the NiceConnection.
2. remove spurrious NiceConnection->start() call; no longer does any work.
3. Remove spurrious queue item call in WebRtcConnection.cpp; setting the "bail" variables and firing the condition object works just as well.
Fix deadlock with SdesTransport, clean up locking

WebRtcConnection would deadlock writing to a SdesTransport because it would hold receiveVideoMutex_ while calling into Transport->write(); on SdesTransport, however, it would ultimately call back into WebRtcConnection::queueData, which attempts to hold receiveVideoMutex_.  This causes a deadlock since boost::mutex isn't recursive.

Change this so we don't hold receiveVideoMutex_ when calling into transport->write(); receiveVideoMutex_ now locks only around the queue in WebRtcConnection and does not hold the lock when calling into child classes.
Merge pull request #189 from jnoring/upstream

Add WebRTC's FEC processing to ExternalOutput
Merge pull request #190 from jnoring/lock_improvements

Lock improvements
A few locking changes

1. The Monitor class was essentially doing nothing because the scoped_lock objects weren't actually locking any supplied mutex.  Also, locking before a function call is a bad idea because the bounds of the lock are indeterminate, so do not lock there anymore.
2. Remove the writeMutex_ in WebRtcConnection; it was only protecting a single method that doesn't need protection
3. Remove some unused stuff.
Change WebRtcConnection to use webrtc's fec if necessary

because firefox doesn't support RED/FEC, licode was converting RED/FEC to raw VP8, but it was doing this for everybody, regardless of whether or not they could digest red.  change it so for endpoints that can digest red, we send it straight through.  For those that can't, we use WebRTC's FEC handling to recover missing packets.
Merge pull request #192 from jnoring/improvements

Improvements
Merge branch 'master' into trickle_ice

Conflicts:
	erizo/src/erizo/NiceConnection.cpp
Merge branch 'master' into trickle_ice

Conflicts:
	erizo/src/erizo/WebRtcConnection.h