Refactor dlq queueing and locking

[bjpetit]

I was digging into the dlq queueing code as I was trying to understand why I was getting these messages.
Received frame queue is out of control. Length
Upon some further digging, I believe the number of nodes my bpq instance registers may be triggering this message from time to time. That's why you'll see I bumped the message conditional to 15 in the change.
While I was digging in, I ended up doing a little refactoring on the queueing and locking in this area. The key changes are;

• Eliminate the wake_up_mutex and just use the dlq_mutex.
• Add a queue tail and eliminate walking the queue for each append

I'm currently testing this against my bpq station on one HF FX.25 port, one HF IL2P port and one VHF FX.25 port, and so far things are holding together ok.
One caveat: I haven't tried compiling or testing this against Windows as I don't have a windows system set up at the moment.
But leaving this PR here, in case it is interesting.

[wb2osz]

Thank you for your suggestions to help clean up this mess.
It was a long time ago, but I recall that it took some effort to get it working correctly on both Linux and Windows.
As I recall, there was a difference in the behavior of semaphores. One one platform, they maintained a count, on the other they did not. My work around was to add another variable to indicate whether the queue reading thread was waiting on an empty queue. This might have something to do with two different mutexes, when you might expect one for all of the variables related to the queue maintenance.
I need some time to study this.