Follow-up to #137: Cross-origin redirects can leak Cookie and Authorization headers

I noticed what appears to be a small follow-up to the previous information-leak fix for cross-origin redirects. The current code still seems to preserve `Cookie` and `Authorization` headers when the redirect target is supplied by the runtime HTTP `Location` header rather than appearing in the initial request URL query. I checked this against the latest version.

```js
const request = require('requestretry');

request({
url: 'http://trusted.example/start',
headers: {
Cookie: 'sessionId=abc123',
Authorization: 'Bearer secret-token',
},
}, callback);

/*
trusted.example responds with:

HTTP/1.1 302 Found
Location: http://other-origin.example/collect

Public API: request()
Related internal function: sanitizeHeaders()
Expected: credential headers are removed before the redirected request
Observed locally: the redirected request still contains Cookie / Authorization
*/
```

The existing `sanitizeHeaders()` logic appears to look for external URLs in the initial request query string. That covers cases where the redirect target is visible in the original URL, but it does not cover the normal HTTP redirect flow where the target is supplied later by the response `Location` header.

A possible fix might be to treat a cross-origin redirect as a credential boundary. When the library follows a redirect, it could resolve the `Location` header and compare it with the current request origin. If the protocol, hostname, or port changes, `Cookie` and `Authorization` should be removed case-insensitively before the next request is sent. This would cover redirects discovered at runtime, not only external URLs embedded in the initial query string.