Use a dedicated thread to buffer payloads, so avoiding deadlock

[asajeffrey]

Fixes #2478

The problem is that sending a transaction first sends the payloads, then the transaction. This causes deadlock if sending the payload blocks, since the transaction is never sent, so the payloads are never removed from the buffer.

This PR fixes that, by adding a dedicated thread that routes from the payload IPC channel to a payload mpsc channel. It also removes a hot loop in the case of missing payloads.

---

This change is 

[asajeffrey]

r? @glennw

[glennw]

Some CI tidy failures:

./webrender_api/src/channel_ipc.rs:9: use statement is not in alphabetical order
	expected: std::{error, io}
	found: std::sync::mpsc

[asajeffrey]

@glennw fixed

[glennw]

Looks good! Let's squash the commits and then this is ready to go.

[asajeffrey]

@bors-servo r=glennw

[bors-servo]

📌 Commit 8bed771 has been approved by glennw

[bors-servo]

⌛ Testing commit 8bed771 with merge f461a5b...

[bors-servo]

☀️ Test successful - status-appveyor, status-taskcluster, status-travis
Approved by: glennw
Pushing f461a5b to master...

[kvark]

I wonder why we couldn't send the payload after transaction, which would also resolve the deadlock.

[asajeffrey]

@kvark that would probably fix the problem, but a) it puts the WR thread into a hot loop until the payload arrives, and b) it tightly couples the sender and receiver which then have to agree about which is the current channel, which is rather brittle code. In the long run I think the plan is to move WR over to just using mpsc channels, and move any ipc over to the application.