Deprecate exception.escaped attribute, update exception example

[lmolkova]

This is follow up on open-telemetry/semantic-conventions#1716 - cross signal guidance on how to record errors (and exceptions) in instrumentations.

Changes

Follow up for open-telemetry/semantic-conventions#1716

exception.escaped attribute is not used in practice within OTel instrumentations (checked Java, .NET, JS. Python, Go, C++ and Rust including contrib repos).
OTel instrumentations, in general, don't record handled exceptions, i.e. virtually all exceptions we're recording in non-native instrumentations are expected to escape span scope.

The litmus test whether to record exception on spans is whether the instrumentation is going to set span status to ERROR due to this exception.

A way to record all sorts of exceptions is being introduced in #4333 and leverages logs along with severity that conveys how critical the exception is in more expressive way than exception.escaped flag.

• Related issues Document generic approach for span status (code + description) and exception event when instrumented code throws semantic-conventions#1536, What's the use case for exception.escaped? semantic-conventions#1516
• Related OTEP(s) OTEP: Recording exceptions as log based events #4333
• Links to the prototypes (when adding or changing features)
• CHANGELOG.md file updated for non-trivial changes
• spec-compliance-matrix.md updated if necessary

[carlosalberto]

Overall LGTM, but we should add this note from the semconv repo:

It's no longer recommended to record exceptions that are handled and do not escape the scope of a span.

Mostly because the example seems to imply this, but better be super clear IMHO.

[lmolkova]

Overall LGTM, but we should add this note from the semconv repo:

It's no longer recommended to record exceptions that are handled and do not escape the scope of a span.

Mostly because the example seems to imply this, but better be super clear IMHO.

makes sense, @carlosalberto, updated in 0f7d54c