Windows does not allow setting the locale with environment variables (as
the test attempted to do), so the test failed when run with a user
locale that has a comma as radixchar. Changed the test to call
setlocale() explicitly to ensure that a known working locale is set even
on Windows.

SEND_QUAL_ARG2 had to be set, but was never used. Use it in swrite to
avoid warnings about casting away low-level const.

Closes https://github.com/curl/curl/pull/1464

Fix the following warnings when building the tests by using the correct
types:
cast from 'const char *' to 'void *' drops const qualifier
[-Wcast-qual]
implicit conversion changes signedness [-Wsign-conversion]

Closes https://github.com/curl/curl/pull/1452

Closes https://github.com/curl/curl/pull/1452

Previous TODO wanting to write in chunks. We should support writing more
at once since some TELNET servers may respond immediately upon first
byte written such as WHOIS servers.

Closes #1389

... and instead properly respond with an error message to the user
instead of silently ignoring.

Fixes #1453
Closes #1458

Support for _MPRINTF_REPLACE in mprintf.h was removed in
55452ebd, replaced with curl_printf.h.

Closes #1449

The buffer can have other sizes.

... to properly use the dynamically set buffer size!

It was a wrong assumption that it could do that!

To make it suitably independent of the receive buffer and its flexible
size.

Removes the need for CURL_BUFSIZE

... instead of clobbering the download buffer.

The buffer is needed to receive FTP, HTTP CONNECT responses etc so
already at this size things risk breaking and smaller is certainly not
wise.

Don't clobber the receive buffer.

The definition of TRUE was introduced in
4a728747 and is not used anymore since
e664cd58.
The usage of intptr_t was removed in
32e38b8f.

- Include tool_convert.h where needed.

Bug: https://github.com/curl/curl/issues/1460
Reported-by: Gisle Vanem

Prior to this change it was possible for libcurl to be built with both
Windows' native IDN lib (normaliz) and libidn2 enabled. It appears that
doesn't offer any benefit --and could cause a bug-- since libcurl's IDN
handling is written to use either one but not both.

Bug: https://github.com/curl/curl/issues/1441#issuecomment-297689856
Reported-by: Gisle Vanem

This fixes the following clang warning:
getpart.c:201:17: warning: cast from function call of type 'CURLcode'
to non-matching type 'int' [-Wbad-function-cast]