fdo#87030: Prevent PDF signing using Windows API from failing

There was one details that I had missed in my initial coding:
CryptAcquireContext() doesn't give you a HCRYPTPROV key container that
would contain the private key of a public key certificate. For that
you need to use CryptAcquireCertificatePrivateKey(). When the hash has
been created using such a HCRYPTPROV, the CryptSignHash() call
succeeds.

The certificate in DER encoding that is passed in from the caller,
obtained in the certificate chooser (in xmlsecurity), is possibly not
good enough to be used for the other things. So look the same (?)
certificate up in the user's key store instead. At least more
properties are present in the certificate when looked up like that.

Add more SAL_INFO logging, with cleartext dumping of certificate
context property names and list of algorithms supported by the CSP.

Unfortunately, even if all the WinCrypt API calls now succeed, the
signatures we produce still are not good enough for Adobe Reader... A
lot of information must be missing, they are quite short, just 256
bytes.

Change-Id: Ifa4dd37b6d40932fcdcbb07e00c9eb52d54a5477
fdo#87030: Generate a proper PKCS#7 signature

The signature should be in DER-encoded PKCS#7 format and what CryptSignHash()
produces is nothing like that. Luckily CryptSignMessage() is actually almost
easier to use and is capable of doing what we need. This also means that we
won't need any HCRYPTPROV or HCRYPTHASH after all so all the code related to
that can be removed. CryptSignMessage() handles both calculating the hash and
signing it.

One less than ideal issue with CryptSignMessage() is that it needs all the
data to be hashed and signed at the same time, so we need to keep both buffers
around for signing.

It also turns out that we don't need to look up the certificate anew from the
user's certificate store after all.

Now Adobe Reader doesn't complain any longer about the signature's format and
contents.

Change-Id: I25cfb93b516ffa723c6228d068d9ffa8e7cc4790