Add xcryptobackendswap, implement x/crypto SHA3 using backend

[dagood]

Updates OpenSSL and CNG patches to add SHA3 APIs and SupportsHash. Include these funcs in nobackend.go because that's being used to determine how the proxy is generated in the x/crypto fork.

Adds the xcryptobackendswap experiment, which uses -modfile plus some internal patching to replace any x/crypto usage with a fork of x/crypto contained in GOROOT/ms_mod.

The fork is generated by a tool that applies patches onto an x/crypto submodule, copies it to the specified dir, then generates "proxies" by parsing the crypto backends and nobackend then using go:linkname to access the internal funcs. This tool as well as the submodule and patches can live in microsoft/go-infra for now. The idea is that the patches are toolset- and version-agnostic and we define a common API in nobackend.go that the patched x/crypto uses. For the most part, we control what our backend API looks like (and we can always add more functions that upstream doesn't have), so this might be good enough for compatibility.

Draft things: doesn't include HKDF (will want SupportsHKDF from #1037), I wrote a temporary stand-in for OpenSSL SupportsHash (until #1036 goes in), and the x/crypto fork includes some stdout-prints as a super simple way to tell that it's being reached.

• Tooling draft at Add xcryptobackendgen tool, x/crypto fork go-infra#92
• For Redirect x/crypto APIs to implementations provided by backends for FIPS compliance #986

[karianna]

@dagood - needs a rebase if we are keeping

[dagood]

Indeed. But to be clear, not planning to do that now: IMO, it's been long enough since I wrote this that it would be better to wait to fix it until we truly start working on it again.

[dagood]

I don't see any chance this approach will be necessary. Between upstream FIPS consolidating algorithms and some algorithms being moved into the stdlib regardless, I doubt we'll need to do swaps.