RUM-16325 timeseries: Update RUM JSON schemas and regenerate models

[satween]

What does this PR do?

Updates the RUM JSON schemas to the latest definitions and regenerates the corresponding Kotlin models and API surface. Also improves the json-schema code generator so OneOfPrimitiveOptionGenerator shares the knownTypes registry with FileGenerator, avoiding duplicate type resolution.

Review checklist (to be filled by reviewers)

• Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
• Make sure you discussed the feature or bugfix with the maintaining team in an Issue
• Make sure each commit and the PR mention the Issue number (cf the CONTRIBUTING doc)

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 72.59%. Comparing base (4e287bb) to head (147653a).

Additional details and impacted files

@@                  Coverage Diff                   @@
##           feature/timeseries    #3555      +/-   ##
======================================================
- Coverage               72.62%   72.59%   -0.03%     
======================================================
  Files                     980      980              
  Lines                   36053    36053              
  Branches                 6033     6033              
======================================================
- Hits                    26181    26171      -10     
+ Misses                   8198     8197       -1     
- Partials                 1674     1685      +11     

Files with missing lines	Coverage Δ
...nal/timeseries/serializer/MemoryEventSerializer.kt	87.72% <100.00%> (ø)

... and 36 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[aleksandr-gringauz]

OneOfPrimitiveOptionGenerator shares the knownTypes registry with FileGenerator, avoiding duplicate type resolution

Yes, we already have this knownTypes mechanism and it makes sense to add it to the OneOfPrimitiveTypeOptionGenerator.

No call to action, just a thought.

I have once concern about this knownTypes approach in general (not only in oneOf(primitives) case) - the name of the resulting class depends on the order of traversal. For example in ViewEvent we have 2 structurally identical fields: context and featureFlags. In ViewEvent they have a type Context. It is weird that featureFlags field has type Context that has nothing to do with it`. Also if we at some point introduce a third one the name can change for already existing ones breaking the backward compatibility.