Add FFI bindings for the libcurl URL parsing APIs

[rdw-software]

Needs benchmarking to determine whether the overhead is significant. If yes, also create a C++ wrapper.

Preliminary results from a few simple/throwaway microbenchmarks suggest:

• If the components rarely or never change, the JIT-optimized traces will run faster than a pure C++ implementation
• For crypto-RNG'ed components of moderate length (256 byte tokens), C++ is slightly (10-20%) faster
• Varying the token lengths does affect the runtime (moderate effect), but parsing itself isn't a bottleneck
• For very short components the C++ version is slightly slower or faster, depending on the exact size
• I'm guessing this is due to how allocations take place as it changes drastically at power-of-two boundaries
• For very large sizes (several KB to MB), "naive" alloc-free sequences are evidently causing a huge slowdown

Regarding size limits:

Although libcurl claims to support up to 8MB for each URL component, that limit seems impractically high. I've therefore limited my testing to the more sensible range of up to 2 KB max. At this point it seems that the actual time is dominated by allocations and cleanup (free), which isn't yet optimized but should be - see note below.

Semi-related:

The built-in allocator should be integrated with libcurl in any event, same as for some of the other libraries, but that's something of a future concern. Libcurl does offer an API to do it, but that's not currently being used.

Basically, it doesn't seem worth optimizing these bindings right now. Allocations are already on my (long) list.