Audit getaddrinfo() uses for proper freeing, redmine #6539.

When getaddrinfo succeeds, we presume that response is non-NULL; i.e. that it won't "succeed" with an empty list, since that would be covered by this documented error return:
```
       EAI_NODATA
              The specified network host exists, but does not have any network
              addresses defined.
```
Where getaddrinfo fails, we test response for NULL (to which we'd previously initialized it) because we've heard (from @xrg, IIRC) that some implementations can leave the response pointing at a partial response list when failing due to OOM.  Unfortunately, we now learn that some implementations expect us to ignore the response list they've allocated - but also free'd - when failing due to OOM.  So we have a bit of a tricky problem here.

The root cause is that the POSIX spec for getaddrinfo fails to say what happens on failure (as it also fails to say whether freeaddrinfo(NULL) is, like free(NULL), a valid call; some zealots at FreeBSD appear to have decided that crashing on freeaddrinfo(NULL) is perfectly sane behaviour, so we guard against this).  The spec doesn't say that, on failure, the value of response should be ignored; nor does it say that, (even on failure) if it's been set to a non-NULL value, then the caller has a duty to freeaddrinfo() it, nor does it say anything else about what we should do with it on failure.

I believe we should ignore getaddrinfo()'s response list on failure.  At worst we'll leak partial lists that we can justly claim getaddrinfo() should have tidied up for itself; whereas, at present, we're in danger of a double freeaddrinfo() when we call this on the response list from a getaddrinfo() - such as the one in our own libcompat - that's already called freeadrinfo() but neglected to set the response list back to NULL before returning an error code.