Upgrade to smoltcp version 0.9; fix the VPN locking up and spin-looping

This is a multi-patch series; the commit descriptions are pasted below:

the smoltcp upgrade commit

• We upgrade our smoltcp version from 0.8 to 0.9.1, incorporating a bunch of very useful changes.
• The smoltcp Interface no longer owns its socket set and device, which lets us only share the socket set across tasks; the device and interface can be solely owned by the main loop, reducing the amount of locking needed.
• We clean up TcpSocket and UdpSocket's new() functions, making them just take an &OnionTunnel for simplicity.
• This also means we can move the PcapWriter out of the interface when packet capturing is not enabled, which is a lot cleaner.
• We no longer ignore smoltcp poll_delays of zero; instead, we keep track of when the interface's transmit buffer is full, and don't bother asking smoltcp for a poll delay in this case.
• If the transmit buffer is indeed full, we won't be able to send any more, but smoltcp will still try to, resulting in spin looping for no reason.
• We might still get poll_delay of zero in some cases, but it doesn't seem to lead to pathological spin-looping behaviour any more.

the locking up fix commit

• The PollableAsyncDevice previously tried to be clever, only attempting a write if it was notified to wake up because a new packet was just added to the TX buffer.
• This is a flawed approach: if the write fails due to the device not being ready, we won't retry it until a new packet gets added!
• And if the buffer is full, we won't ever add any new packets, and we won't ever write, and the entire VPN locks up!
• Fix this oversight by just having one semaphore to wake up the async device, and indiscriminately polling both read and write halves every time.
• This is far less clever, and it might be a performance problem ages down the line, but simple is probably best...!

oh yeah, this also fixes #49 (closed) -- please close that for me, gitlab