Umpire VS desktop-streaming

* https://github.com/joshhansen/Umpire

The reason for this is that I'd like to use an RAII pattern to control player turns in Umpire. When the struct is initialized, it starts the player's turn, and when the struct is dropped, it ends the player's turn.

Wound up with some time so I figured I'd port my Umpire military strategy game to a client-server architecture so people can play it online. This will give me some experience with Tokio, tarpc, and async Rust generally, since I'm eyeing a possible Rust dev gig in my future.

I've done a little bit of Rust development on Windows and had a good experience. I ported my (still unfinished) Umpire game to Windows pretty easily. I had to rename some files that had colons in the filename which Windows didn't like. The actual hard part was the terminal library, but switching to crossterm was pretty straightforward. All in all it was pretty painless.

I'm using webrtc-rs for my personal project and their RTP stack is chock full of allocations/deallocations. I, on the other hand, prefer to use preallocated buffers so I find myself having to reimplement a lot of RTP functionalities.

Finished the native Android client of my desktop streamer and latency still sucks. I looked over at Moonlight's code and they have lots of vendor-specific hacks for lowering latency. But I can't just copy that because: 1) it's GPL, 2) I'm doing the decoder initialization purely in Rust so I don't have convenient access to the Java methods.

I found it easier to integrate NvEnc to webrtc-rs. libwebrtc is too tightly integrated and would need a massive C++ shim. Would like to see how your implementation would look.

Made a desktop streamer using Window's IDXGIOutputDuplication API and the webrtc crate.