Add client-side jank event

[breedx-splk]

This adds a new event called app.jank that can be used to report when an application experiences slow rendering.
It is a restart of #2157, intended to be simpler and without the need to discuss why metrics aren't a good fit for client-side reporting of jank. It also omits the activity name and classifier (slow/frozen) to hopefully reduce contention and allow us to build experimental semconv incrementally.

In pseudocode, the jank event looks like this:

{
  event_name: app.jank,
  timestamp: <standard log/event timestamp>
  attributes: {
    app.jank.count: 3,
    app.jank.period: 5.0,
    app.jank.threshold_ms: 16
  }
}

That's it.

The idea is that when RUM (real user montoring) users are looking at a session timeline, it can be helpful to have some indication when slow renders happen, because it influences user interaction behavior. This event is not intended to be a continuous signal like a metric, and it should only be reported for small intervals when jank is detected.

This semconv also does not specify behavioral aspects of instrumentation. For example, some implementations might report more than one jank event for the same period, but with different thresholds. This is purposefully not covered by this semantic convention. It is purely intended to define the event and specify which attributes are expected on the event.

Another reminder for reviewers, because this is not always obvious: Most of the content (everything between html style comments) in the docs/markdown files is auto-generated from the yaml, so comments about that should probably be comments about the source yaml.

Merge requirement checklist

• CONTRIBUTING.md guidelines followed.
• Change log entry added, according to the guidelines in When to add a changelog entry.
  • If your PR does not need a change log, start the PR title with [chore]
• Links to the prototypes or existing instrumentations (when adding or changing conventions)

[bidetofevil]

LGTM. I would do the s/sount/[frame_count|frames] rename but that's only a slight preference and is non-blocking.

I have a nit that I will follow up separately 😅

[LikeTheSalad]

Cheers!

[lmolkova]

LGTM with some cosmetic suggestions. Also I assume there are existing instrumentations/prototypes that report this event - could you please add links to them in the PR description?

[lmolkova]

@breedx-splk could you please add links to instrumentations/prototypes to the PR description? thanks!

[jsuereth]

@breedx-splk Can you add a link to the prototype in the PR description?

[breedx-splk]

@breedx-splk Can you add a link to the prototype in the PR description?

Sure. I hope to have something worked up this week. It's kinda funny, because we currently use a zero-duration span in Android, and part of the goal of having a semconv was to be able to switch to an actual event....so 🐔 🥚 situation. But I think I have a way forward.

[breedx-splk]

@breedx-splk Can you add a link to the prototype in the PR description?

Ok here open-telemetry/opentelemetry-android#1175
There's more than one thing happening there, but the main event generator is this class here: https://github.com/open-telemetry/opentelemetry-android/pull/1175/files#diff-cecbb46cb90250501402cd2fd1405454f7fa168746edd2bc1681902e08e692a2R21