No explicit bound on issuance log size (index/tree_size)

[Vaisman]

Section "Issuance Logs" describes an issuance log as an append-only sequence of entries identified by an index starting from zero,
with no stated upper bound. The only explicitly bounded quantity in this area is the log number itself:

"Log numbers are numbered consecutively from 1 to at most 65535 (2^16-1)."

However, the certificate format depends on the log entry index and subtree boundaries fitting in 48 bits.
Section "Certificate Format" defines:

"The serialNumber MUST be equal to (log_number << 48) | index."

and MTCProof's start and end fields are typed as uint48. Verification reconstructs the split the same way:

"Let index be the least significant 48 bits of serial and let log_number be serial >> 48."

None of this is tied to a normative bound on index or the log's tree_size.
There does not appear to be a statement requiring an issuance log to remain small enough for all certificate-relevant values (index, start, and end) to fit in uint48.

If a log grew beyond the range representable by the certificate fields, the certificate format would no longer have a well-defined way to represent later entry indexes in serialNumber or subtree boundaries in MTCProof.start / MTCProof.end.
This is the same kind of asymmetry that is already handled for log numbers, which are explicitly bounded at 65535; index / tree_size do not seem to have the corresponding statement.

Suggested fix: Add an explicit requirement defining the maximum allowed issuance log tree size, chosen so that all certificate-relevant indexes and subtree boundaries fit in uint48.

[davidben]

Coincidentally did this in #261 before I saw this bug.

(This is, of course, not really a concern. Even if you issued 1,000 certificates a second, it would still take you almost 9,000 years to reach 2^48.)