Add FFI bindings for blocking network transfers via libcurl's easy interface

[rdw-software]

Status: TBD (don't remember)

TODOs:

• Review variadic functions - they don't map cleanly to the FFI (need to box arguments IIRC?)
• Maybe they can be skipped/replaced as they don't feel very idiomatic when translated to Lua
• Reduce boilerplate, via automation or higher-level wrappers if need be
• Review integration with the shared event loop, don't recall if this was a potential problem or not

---

First part of binding the blocking client APIs from libcurl. There's a few ugly parts that won't map cleanly:

curl_easy_setopt_by_name replacing curl_easy_setopt

The plan is to export a custom wrapper API instead of the one that curl offers to set transfer options:

• libcurl uses numeric IDs for the options, but generates them with macro expansions and offsets
• I really don't want to sync even more types (ideally none, but that's not happening anytime soon)
• Ergo I'm not going to duplicate the preprocessed header types, or generate them on-the fly
• Instead, the API should take the name and/or curl_easyoption pointer and handle the rest
• There's probably no one who wants do pass random numbers from Lua anyway... so yeah, let's not

If curl_easy_setopt isn't going to be exposed, the name can be reused. Otherwise, it could get an alias.

curl_easy_getinfo_by_name potentially replacing curl_easy_getinfo (?)

I'd rather not duplicate CURLINFO even though it's not as problematic. Maybe another name-based lookup function will do? In that case, there's probably no need to deal with numeric IDs. I'll need to do some more testing first.

curl_easy_ssls_export and other callback-based APIs

Callbacks really aren't something I like to see, but they just won't die. Unlike the VM, when JIT optimizations aren't disabled. It won't be an issue for curl's easy interface because it's blocking. But for parallel transfers (multi interface) and the libuv integration, there might not be any way around implementing another event/polling wrapper API. Not great?

NYI: Async DNS resolution

The blocking transfer APIs aren't going to break any speed records. So it shouldn't be a problem if DNS resolution uses the default mechanism. On Windows, it seems like AsynchResolver is actually enabled by default... lucky accident.

---

Resolves #655 (once done). Still needs testing for at least the most basic use cases, and name-based lookups.