Removes warnings about using deprecated inet function

[supperpiccle]

The warning in question is: "Warning C4996 'inet_ntoa': Use
inet_ntop() or InetNtop() instead or define
_WINSOCK_DEPRECATED_NO_WARNINGS"

Simply adding the _WINSOCK_DEPRECATED_NO_WARNINGS preprocessor silences
the warnings.

[Nekotekina]

Well, this function is really problematic unless it stores its result in thread-local storage (it probably doesn't)

[supperpiccle]

I would have imagined that if this caused issues, it would have already. If you would prefer, I'll just replace all uses of inet_ntoa to a safer function.

[Nekotekina]

Replacing them should be safer. Alternatively, it could be implemented as a formatting function specialization for in_addr since it's required to be a big-endian 32-bit integer with somewhat obscure specification.

[supperpiccle]

Updated PR by removing the first commit and replacing all uses of inet_ntoa with inet_ntop.

[supperpiccle]

Upon further reflection, it seems this code is called rarely enough that we could justify having a helper function that returns an std::string and we use the .c_str() member function for these logging messages. It will have to be a stack allocated variable though, but would remove the ugly inet_ntop calls and the assumption that we report ipv4 addresses.

Open to feedback here.

[RipleyTom]

I mean that function already exists in the code, it's ip_to_string.
A specialization of formatter for in_addr seems also like a good idea to me(as the vast majority of the formatting is for those logging calls). Also no need to use .c_str(), the formatter can handle std::string fine.

[supperpiccle]

I assumed that we were passing the format string + data to a printf family function. I did not know that rpcs3 had an implementation of format string generation.

While I agree having a format specifier that takes a in_addr seems cool, I have a feeling that this special specifier for this and leaving it undocumented will lead to us using it in this PR and forgetting about it. The solution might be to simply extend some of our dev docs to include these special format specifiers. Y'all may not agree with this sentiment in which case, I'll just make the change 😄 .