feat: CLE support

[taleodor]

This PR introduces CLE (ECMA-428) support to TEA.

[oej]

I don't see why the CLE requires special attention like this, it's just an artefact.

We discussed earlier to extract the current CLE state into the component.

[taleodor]

I don't see why the CLE requires special attention like this, it's just an artefact.

I should have referenced this in the description, but some reasons were discussed in #106

The other part of the reason is that the expectation for API is to increasingly provide information directly rather than just fetch documents.

Why CLE is a prime candidate for special treatment like this:

A user (human or bot) of TEA always wants up-to-date CLE metrics. CLE document is a time series document. Summing this up, on every CLE change with document-based approach, a new document must be uploaded to TEA. And if we try "simplified" approach with a single field per-release, than such document must every time be parsed by TEA server and every release be updated.

If that is the expected workflow here, it is much easier to just make CLE 1st class citizen and directly update response on every CLE change.

[taleodor]

One more thing to mention: version is an optional field in CLE spec, so when CLE is used under a release, version should be omitted as it's clear that CLE belongs to the release.

[oej]

#106 keeps the CLE as an artefact and discuss whether to take some fields out, like I said before. It does not discuss creating a specific API endpoint for CLE.