Determine the maximum log plaintext length

[nventuro]

#11641 naively allocates the entire private log size to the ciphertext, but this is incorrect: there's also the tag, headers, encryption padding, etc. We need to account for this to produce a better limit.

Given users can introduce alternative encryption schemes, we could initially either choose to a) assume they're using our own, or b) set some upper bound for the overhead and hope their scheme does not require more metadata than what we allocate.

[iAmMichaelConnor]

I don't follow this one. The aim is for advanced users to be able to design their own log layouts, and the recent refactor enables that. The checks on whether the layout fits within a log should be done within the custom log strategy file (e.g. within default_aes128/note.nr)

[nventuro]

I guess in the end it'll be multiple checks, and whichever one is strictest will be the one that actually matters. So e.g. the aztecnr note macro will fail if say your note would be packed into more than 13 fields, but a very inefficient encryption scheme might then fail if you're using it with your note that packes into more than 6.