Switch to ureq for our simple sync HTTP get request

[DavisVaughan]

Turns out that you aren't allowed to call reqwest::blocking::get() from inside tokio::block_on()

reqwest uses tokio internally, which means that reqwest::blocking::get() tries to use tokio blocking APIs, but when you're already inside a tokio runtime (which we are due to our top level tokio::block_on()) you can't use any additional tokio blocking APIs. It results in a full panic and a confusing message.

You can supposedly do stuff like this to push the blocking work onto an actual blocking thread used by tokio

let resp = tokio::task::spawn_blocking(|| {
    cache::get("dplyr")
}).await.unwrap();

but thats so awkward to think about, especially considering that we want the cache to be "warm" most of the time, not requiring tokio at all.

---

Instead, I think we should switch to ureq, which is one of the other popular but more minimal HTTP clients and is always blocking, which is fine for us right now.

This still requires the tweaks to the Windows github action. ureq uses ring under the hood (at least for now, see algesten/ureq#1141). On ARM Windows where we have an MSVC target of aarch64-pc-windows-msvc, ureq needs to compile in a lot of C code with clang, but ends up finding the Rtools MinGW tooling that is put on the PATH, and that causes it to fail with an <assert.h> missing header error.