SPEC: Lifecycle dates in TEA leaf

The current OpenAPI spec only provides an `end_of_life` date for a TEA leaf. This single date might be a little bit reductive. While the CLE specification provides a lot of dates, for the purpose of TEA IMHO two dates should be reported:

- the end of security **updates**: after this date no further releases of the TEA leaf will appear. Users still can continue using that version with a slightly increased risk. If something happens, they will need to upgrade to a newer leaf of the same product.
- the end of security **checks**: after this date the producer will not even accept new security reports for that leaf nor check if this leaf is affected by CVEs of other leafs of the same product. This is the real End-of-Life.

In Apache Log4j leafs will correspond to `MINOR` versions (`2.23.x`, `2.24.x`, …). Since we are very strict on what constitutes a minor version bump (a single new public method in a public package forces a minor version bump), we have minor releases every 3 to 6 months. Security updates are only published for the latest minor version. In practice this mean that 90% of our user base is on a TEA leaf with **no security updates**.

I think that it is fine for user to miss the end of security updates (especially when semver is involved), but tools like Dependency Track could take that into account and:

- warn a user, if he uses a TEA leaf with **no** security updates,
- warn a user, if he uses an outdated version of a TEA leaf **with** security updates (the patch release might be a security update not yet announced),
- **don't** warn a user, if he uses the latest patch release of a TEA leaf **with** security updates.

https://github.com/CycloneDX/transparency-exchange-api/blob/6b90fd4b82b8c253551ee05f8f5ae601be2ea031/spec/openapi.json#L997-L1038