Withdraw support for SHA-512-256 in HTTP Digest.

I was dubious about it to begin with, when I found that RFC 7616's
example seemed to be treating it as a 256-bit truncation of SHA-512,
and not the thing FIPS 180-4 section 6.7 specifies as "SHA-512/256"
(which also changes the initial hash state). Having failed to get a
clarifying response from the RFC authors, I had the idea this morning
of testing other HTTP clients to see what _they_ thought that hash
function meant, and then at least I could go with an existing
in-practice consensus.

There is no in-practice consensus. Firefox doesn't support that
algorithm at all (but they do support SHA-256); wget doesn't support
anything that RFC 7616 added to the original RFC 2617. But the prize
for weirdness goes to curl, which does accept the name "SHA-512-256"
and ... treats it as an alias for SHA-256!

So I think the situation among real clients is too confusing to even
try to work with, and I'm going to stop adding to it. PuTTY will
follow Firefox's policy: if a proxy server asks for SHA-256 digests
we'll happily provide them, but if they ask for SHA-512-256 we'll
refuse on the grounds that it's not clear enough what it means.

proxy/nocproxy.c

@@ -20,7 +20,9 @@ strbuf *chap_response(ptrlen challenge, ptrlen password)
     unreachable("CHAP is not built into this binary");
 }
 
-const char *const httphashnames[] = { NULL }; /* dummy to prevent link error */
+/* dummy arrays to prevent link error */
+const char *const httphashnames[] = { NULL };
+const bool httphashaccepted[] = { false };
 
 void http_digest_response(BinarySink *bs, ptrlen username, ptrlen password,
                           ptrlen realm, ptrlen method, ptrlen uri, ptrlen qop,