reject trailing data when parsing signed certificate timestamps

[dxbjavid]

Signed Certificate Timestamps embedded in a certificate are parsed by a small hand-rolled TLS reader rather than the DER machinery. The reader walks the length-prefixed list and then each fixed SCT structure, but it never checks that it reached the end of either, so any bytes left over after the list, or after the final signature field inside an individual SCT entry, were quietly discarded. Since the SCT bytes come straight from an untrusted certificate extension, a malformed encoding with appended padding parsed as a valid SCT, and the leftover bytes still ended up in the stored raw data used for equality and hashing. I noticed it while comparing this reader against the DER and SSH parsers, both of which reject leftover input. The fix verifies each reader is empty once the expected fields have been consumed. I kept it inside parse_scts and added a regression test covering both leftover positions.

[alex]

In general, unless there's a compelling reason to do otherwise, we prefer to test things from the Python API.