Sorry it took me so long to take a proper look at this. I've added a few safety checks, macOS implementation and C API.

As we didn't have any existing functions in the C API that return strings of unknown length, I wasn't quite sure what would be the best way to do so.

I ended up going with an approach where the library by default dynamically allocates the memory needed and then returning it to the caller, with a way for the caller to choose how to allocate the string. I initially thought about webview_get_url taking an output buffer and max size, but I thought it would increase the complexity both for the caller and the library when having to deal with input validation errors and buffers that aren't large enough.

I remember testing this PR a while back and found that we can't always expect webview_get_url() to return the same URL given to webview_navigate() immediately after navigation has begun. For example, it might be OK with WebKitGTK (Linux), but with WebView2 (Windows) we might get about:blank, and the expected URL after pumping the message loop for a while.