Support for identifying the correct CRL for a subject, and finding a serial in the CRL.

[cpu]

Once CRLs are provided (#55) we need to identify the correct CRL to consult for a given end entity certificate.

I'm strongly in favour of not supporting delta CRLs, since their implementation is significantly more complex than for full CRLs and ecosystem support seems very minimal. Similarly, I would advocate for not supporting indirect CRLs, since their support in the broader ecosystem is also minimal and it would complicate implementation.

With those two considerations off the table I believe we can identify the correct CRL based on matching the end entity certificate's issuer to the CRL issuer.

Once the correct CRL is identified (and validated, see #52 and #53), we also need to search the revoked certificate entries within the CRL for the end entity certificate's serial number. In some implementations (e.g. BoringSSL), the CRL's revoked certificate entries can be maintained in sorted order to allow a binary search for the serial. This would prevent linear scan of the CRL content (which can often be quite large), but I believe would require allocation to implement in webpki.

[cpu]

We will need to take particular care for the serial number search with respect to mis-encoded serial numbers. E.g. see Brian Smith's comment on a related issue.

[cpu]

This was implemented in #66 with the optimization question separated into #80

Serial numbers are handled as a byte-for-byte comparison between the certificate and the CRL entries. It might make sense to revisit that choice for misencoded serial numbers but I think it's a bit of an edge case and I'd need to find some real world examples where the certificate serial number was correctly encoded in one place but not the other.