Continued extension representation rework

[cpu]

This revives and continues the extension rework from #446 and continues where #449 left off by starting on breaking changes. Each extension is now its own type in a new ext module, with the presence decision living next to the encoding.

Serialization builds an Extensions collection first and only writes what was actually built, so the bug class that produced silently dropped extensions is addressed more structurally.

Throughout duplicate OIDs are rejected instead of silently emitted, on both the write and parse sides (#155).

Along the way this grew some related changes:

• extensions borrow from params instead of cloning
• the path length enum was renamed PathLenConstraint to free up the BasicConstraints name for the extension type and because it's more precise.
• SKI is now emitted for end entity certs too (I think this is the right default), and the CustomExtension/ACME identifier API got a rework.
• Some parameters (e.g. name constraints) were changed to prevent invalid states from being represented earlier than ext construction.

Resolves #155
Resolves #446

The next branch continuing from here will pick up some CSR + custom extensions improvements on top.

[cpu]

cpu marked this pull request as ready for review now

Rebased on main and carried forward the tweaks from #456 throughout.

[djc]

Suggest we split this once more, before the AcmeIdentifier inclusion?

Two concerns remaining (somewhat from the previous PR):

• It feels like in a number of cases, this is wrapping a local type in another local type, when we could arguably implement Extension for the existing type rather than wrapping it in another layer.
• The from_params(params: ..) -> Option<Self> pattern feels somewhat overwrought? Especially to the extent we can reuse existing types, can we just have write() yield bool instead of having this indirection between something that exists, then is written?

[djc]

• The from_params(params: ..) -> Option<Self> pattern feels somewhat overwrought? Especially to the extent we can reuse existing types, can we just have write() yield bool instead of having this indirection between something that exists, then is written?

Oh, I guess this is necessary because we only want to write the extensions wrapper when we know there are 1+ extensions to write? Still wondering if there isn't a more light-weight pattern at least for some of the extensions.

[cpu]

Still wondering if there isn't a more light-weight pattern at least for some of the extensions.

I will noodle on this when I split it up & address your other feedback. This part of the solution is more or less as-is from 2023 (time flies!) and I wouldn't be surprised if in 2026 I have a better idea 😆

[cpu]

Still wondering if there isn't a more light-weight pattern at least for some of the extensions.

I think I arrived at a solution that's less heavy weight and let me drop a bunch of types that were just wrappers on top of existing types. More of the extension code is now directly implemented on the pre-existing params types. The only cases where that isn't true we're imposing some additional context on top in a way that felt justified.

As a result the branch grew some new commits in two categories:

1. I undid some of the wrapper types that were added in Rework X.509 cert/csr/crl extension representation #449 - sorry for the churn there.
2. I shifted left some of the validation that was being done in wrapper types to be part of the parameter types directly. This mainly involves making illegal states impossible to represent at the param stage instead of catching it at the ext serialization stage. I tried to avoid doing anything that made the params cumbersome to construct.

Suggest we split this once more, before the AcmeIdentifier inclusion?

Done. I'll rework the remaining bits that were dropped from this branch after this one is ready to go.

I think this is ready for another review pass when you have time.