[Enhancement] Add Nullable annotations to nullable Message getters and fix kotlin-stdlib transitive leak

### Before Creating the Enhancement Request

- [x] I have confirmed that this should be classified as an enhancement rather than a bug/feature.

### Summary

Two independent issues:

1. Seven getters in `Message.java` return null at runtime but have no nullability metadata. This causes silent NPEs and prevents both Java IDEs and Kotlin from warning the caller.
2. A pure-Java project depending on `rocketmq-client` transitively receives `kotlin-stdlib` on its classpath via an uncovered okhttp dependency edge.

### Motivation

**Nullable getters:** `getTags()`, `getKeys()`, `getProperty()`, `getUserProperty()`, `getBuyerId()`, `getProperties()`, and `getTransactionId()` all return null under normal conditions (e.g., `getKeys()` is null unless explicitly set; `getTags()` is null when the producer omitted the tag). A Java user reported the same `getTags()` null problem in [#1453](https://github.com/apache/rocketmq/issues/1453) in 2019 — the issue was closed with no annotation or fix.

**kotlin-stdlib leak:** Upstream already wrote `kotlin-stdlib` exclusions for the `okio-jvm` dependency edge. However, an independent path — `opentelemetry-exporter-otlp` → `opentelemetry-exporter-sender-okhttp` → `okhttp` — still brings `kotlin-stdlib` in. This ships Kotlin's runtime to every user, including pure-Java projects that have no Kotlin dependency.

### Describe the Solution You'd Like

**Nullable getters:** Add `@Nullable` (`javax.annotation.Nullable`, already available via `org.apache.tomcat:annotations-api`) to the seven affected getters in `Message.java`. This is a pure-metadata change with zero behavioral impact.

**kotlin-stdlib leak:** Extend the exclusion to cover `com.squareup.okhttp3:okhttp` and `com.squareup.okhttp3:okhttp:3.x` (which transitively pulls `kotlin-stdlib-jdk8` and `kotlin-stdlib-jdk7`) in the `opentelemetry-exporter-otlp` dependency declaration. This enforces the constraint upstream already wrote for `okio-jvm` — no new policy decision required.

### Describe Alternatives You've Considered

-

### Additional Context

-

Start in Message.java and inspect the seven named getters and existing annotation dependencies. Then inspect the opentelemetry-exporter-otlp dependency declaration and the existing okio-jvm exclusions, and use the dependency tree to trace the okhttp paths. Done means the getters expose nullable metadata and pure-Java users no longer receive kotlin-stdlib through the stated path, with relevant tests or dependency checks passing.

Written by the indexing model from the issue text.