crypt32: Revert 8ed5a777de6c9797a285829e07d7a27b3ed01257.

crypt32: Revert 8ed5a777de6c9797a285829e07d7a27b3ed01257.

Ordinarily removing tests seems like a bad idea, but in this case it
seems the only rational response to the test failures the tests
produce.  The tests check the state of three bits with a variety of
certificate and CRL combinations.  One of these bits is apparently not
set by any version of Windows for any of the tests.  Testing its
absence doesn't seem correct, and I'll explain why in more detail in a
second.  Every permutation of the remaining two bits appears on at
least one Windows version, and no Windows version is obviously more
correct than the rest, so testing them doesn't seem worthwhile.

The one bit that doesn't appear to be set is the bit saying that a
certificate is revoked.  I created CRLs that do in fact revoke some of
the tested certificates, so it appears to me that the bit should be
set.  It's possible that Windows doesn't bother checking the
revocation status of a certificate whose anchor isn't trusted, but
it's impossible to test this in an automated regression test suite,
because adding a trusted certificate requires clicking OK (or its
equivalent) in a dialog.  The dialog is invoked by the system process,
so I can't use a dialog hook to suppress it.  I can test this
hypothesis manually, but it isn't possible to do so in an automated
way.