Add configs for 2025 ceremony (#18)

Add config and output files for our 2025 root and intermediate ceremony.

The 2025 ceremony includes:

The creation of two new roots, Root YE and Root YR, the ECDSA and RSA roots in our Y generation, respectively.
Cross-signs of each of those new roots from our old roots, ISRG Root X1 and ISRG Root X2, as well as a renewal of the cross-sign of X2 from X1 for maximum compatibility.
Three new ECDSA P-384 intermediates under Root YE, named YE1, YE2, and YE3.
Three new 2048-bit RSA intermediates under Root YR, named YR1, YR2, and YR3.
New CRLs from all four roots.

This hierarchy differs from our prior hierarchy in a few key ways:

We are generating two roots (one of each algorithm) instead of just one at a time. This will allow us to move our RSA and ECDSA (and potentially future post-quantum) hierarchies forward in lockstep, without having to worry about different ages and levels of ubiquity between them.

Thanks to this generational approach, we’ve also adopted a new naming scheme. This new generation of our hierarchy is designated as “generation Y” (appropriately following our current “generation X”), with the roots named “Root YR” and “Root YE”, respectively. The intermediates under each of those roots share their name, and are differentiated by small integers, so the intermediates are named “YR1”, “YR2”, etc. Because we’ll be able to reset the intermediate numbering every time we issue a new generation of roots, we expect the numbers to stay smaller than our current intermediate “R14”.

Speaking of names, we’re shortening those. Our new roots have a Subject Organization Name of simply “ISRG” (rather than the much longer “Internet Security Research Group”), and they have dropped the redundant “ISRG” from their Subject Common Names. This is part of our constant efforts to minimize the number of bytes transmitted during every TLS handshake, to help save global bandwidth.

The cross-signs onto these new roots have 7-year validity periods, rather than the 5-year validity period used by our prior X2-by-X1 cross-sign. This is so that the cross-signs won’t be quite on the verge of expiring when the time of our next root ceremony (presumably 2030) approaches.

Finally, and perhaps most imporantly, none of the new intermediates assert the tlsClientAuth Extended Key Usage. This is to comply with modern Root Program requirements which state that “All corresponding unexpired and unrevoked subordinate CA certificates operated beneath an applicant root CA MUST, when disclosed to the CCADB on or after June 15, 2025, include the extendedKeyUsage extension and only assert an extendedKeyUsage purpose of id-kp-serverAuth.” This means that all Subscriber certificates issued by this hierarchy will be serverAuth-only, as we already announced.

Let’s Encrypt Key Ceremony Demos

This repository contains ceremony config files nearly identical to those used for various root and intermediate ceremonies conducted by Let’s Encrypt over its history. You can see the outcomes of those real ceremonies on the Let’s Encrypt Chains of Trust page. You can inspect the configs for each historical ceremony in //ceremonies/YYYY, and the corresponding outputs (demo public keys and certs, but not private keys and not the real outputs produced by the actual ceremonies) in //outputs/YYYY.

It is also used to develop and demonstrate new config files for upcoming ceremonies. To prepare for an upcoming ceremony:

Install SoftHSMv2:
```
sudo apt install softhsm2
```
Create a new //ceremonies/YYYY subdirectory, and populate it with:
- a README.md describing the ceremony;
- the necessary yaml files for the kind of ceremony you’re preparing; and
- a run.sh which pins a specific version of the boulder ceremony tool to use.
Add your new ceremony’s run.sh to run-all.sh.
Execute the ceremonies. Note that it’s not generally feasible to execute only the newest ceremony: this is because many ceremonies involve cross-signs from previously-generated roots, and that requires access to those roots’ private keys. Since we don’t check any private keys into this repo, you have to regenerate everything from the beginning of time:
```
./reset.sh && ./run-all.sh
```
Once you’re happy with the results, update the //outputs directory with the results from your new ceremony, and updated versions of all the historical ceremonies:
```
./update-output-files.sh
```

If you’re working on making changes to the boulder ceremony tool itself, you can point the various run.sh scripts at a specific binary using the CEREMONY_BIN_YYYY environment variables, for example:

export CEREMONY_BIN_2025=/path/to/active/development/boulder/bin/ceremony
rm ceremonies/2025/*.pem && ./ceremonies/2025/run.sh

If you run into difficulties communicating with the softhsm when you do this, you may also need to explicitly point it at the repo’s config file:

export SOFTHSM2_CONF="$(pwd)/softhsm2.conf"
rm ceremonies/2025/*.pem && ./ceremonies/2025/run.sh