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

[rdw-software]

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.