cert-checker: consume MTC logs

Once we're issuing trusted MTCs, we'll need cert-checker to be able to check them post-issuance. For some checks, like SAN blocking and general linting, the TBSCertificateLogEntry structs will suffice, though we'll need to adapt our linting infrastructure to accept them.

For key quality checks in particular, we'll need to consume actual pubkeys, not the hashed SPKI available from TBSCertificateLogEntry. This probably means cert-checker reading tiles and being aware of our local extension to tlog-tiles that stores pubkeys in tiles parallel to TBSCertificateLogEntries.

We should also decide if cert-checker will consume fully-built MTCs (standalone and landmark-relative certificates with MTCProof signature attached). That would allow us to post-hoc audit for syntax errors in building those MTCs. It would require us to log or otherwise store them at the time we build them. The standalone certificates in particular would be big because they contain signatures.

Part of #8738

Start by reviewing cert-checker, the TBSCertificateLogEntry structs, and the related work in #8738. Determine how cert-checker should consume tlog-tiles and whether fully-built MTCs must be stored for auditing. Done means the supported MTC data sources and checks are decided and documented.