TPM2 AK activation/validation seems unnecessarily complicated

Currently TPM2 clients generate an AK and then self-certify using TPM2_Certify.

But I don't think the self-certification is currently serving any purpose:

- TPM2_MakeCredential already guarantees that the reported TPM2_PUBLIC must correctly describes the AK, otherwise TPM2_ActivateCredential won't allow the EK to decrypt the sealed credential.
- For the AK's self-certification to be meaningful, we have to trust that the AK is good, which is kinda begging the question.
- TPM2_Certify *could* be useful if go-attestation checked any of the TPMS_ATTEST fields (e.g., clockInfo or firmwareVersion) or TPMS_CREATION_DATA fields (e.g., it could check that the AK was recently generated), but go-attestation doesn't seem to pay attention to these.

As far as I can tell, if `att.AttestedCreationInfo.Name.Digest` in `generateChallengeTPM20` was replaced with `tpm2.DecodePublic(p.AIK.Public).Name().Digest`, then `p.AIK.CreateData` and `p.AIK.CreateAttestation` can be removed entirely without losing any security properties.

But maybe I'm missing something, or there are plans to eventually utilize more of the attestation data. E.g., maybe firmwareVersion is useful to log in case it's discovered that some TPM firmware versions had key generation vulnerabilities (e.g., [ROCA for RSA keys](https://en.wikipedia.org/wiki/ROCA_vulnerability), or [Yubikey's FIPS RNG goofup affecting both RSA and ECC keys](https://www.yubico.com/support/security-advisories/ysa-2019-02/)); though in that case, you probably need to re-generate (and re-certify) the EK too, so I'm not sure the AK is your biggest concern.