Link libcurl statically

[bpintea]

Add static linking for libcurl and make it the default.

This is useful since the client app might use libcurl and have it loaded
already. Since in this case no second version of the DLL will be loaded
(by default), the driver would have to use that instance, which might or
not have all the necessary features compiled in and behave or not as
expected.

[edsavage]

LGTM

[droberts195]

LGTM

The only thing I would say is that there's a lot of complexity in the build system now to account for the possibility of wanting to dynamically link to libcurl. If static linking is best then I'd just do that, with no option to do anything different.

Since you've already added all the options you might as well commit the PR as is, but after a while if you find that you never ever use the option to link dynamically to libcurl then you could remove the extra complexity.

[bpintea]

Thanks, Ed, Dave.
@droberts195 indeed, keeping the dynamic loading, plus having the release/debug type propagate down to libcurl makes it more complex now. I was thinking of keeping it as is until all parts are in (i.e. also the config editor) and then later possibly restructure it to simplify.
I also hope to be able to switch to curl's CMake, which can already do more than the current "maintained" win build system (ex. skip building the curl.exe, allow disabling non-HTTP protos, || build, setting output destination) and that seems to work just fine for HTTP-only configuration (despite the embedded warning still there).