feat(instrumentation-kafkajs): update semantic conventions

[brianphillips]

Which problem is this PR solving?

Semantic conventions used in @opentelemetry/instrumentation-kafkajs are quite outdated.

Short description of the changes

• Updated @opentelemetry/semantic-conventions in @opentelemetry/instrumentation-kafkajs to version 1.30.0.
• Updated code for span creation to use new attributes/values per semantic conventions.
• Added various metrics per the semantic conventions for messaging systems
• Added tests for the above

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.44%. Comparing base (25b38f3) to head (ba4b39b).
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2752      +/-   ##
==========================================
+ Coverage   89.20%   89.44%   +0.24%     
==========================================
  Files         168      172       +4     
  Lines        8076     8310     +234     
  Branches     1547     1591      +44     
==========================================
+ Hits         7204     7433     +229     
- Misses        872      877       +5     

Files with missing lines	Coverage Δ
...ode/instrumentation-kafkajs/src/instrumentation.ts	97.56% <100.00%> (ø)
...node/instrumentation-kafkajs/src/internal-types.ts	100.00% <100.00%> (ø)
...lugins/node/instrumentation-kafkajs/src/semconv.ts	100.00% <100.00%> (ø)

... and 1 file with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[brianphillips]

This isn't new code but it feels a little bit wrong when compared to the examples in the semantic conventions doc (this one, specifically). All of these process spans for each message will have the same start/end times as the batch itself and I'm not sure that's helpful or intuitive. But for now, I'm leaving that design choice alone and just adding the corresponding metric that the semantic convention requires for all process spans.

[seemk]

Yeah this might be out of scope for this PR. Think creating a single receive span with messaging.batch.message_count attribute would be fine and then add the message offset, parent span context as links, not as new spans. (Trying this out with SQS: #2345)