fix: enforce last-value-wins in AttributesMap for duplicate keys of different types

[kyyril]

Resolves #7897

Changes

Fixes inconsistent last-value-wins behavior in AttributesMap.

Previously, AttributesMap stored attributes directly in a HashMap<AttributeKey<?>, Object>. Since AttributeKey equals/hashCode includes the type, adding two attributes with the same raw string name but different types would result in both being kept, violating the OpenTelemetry specification requirement that setting the same key SHOULD overwrite the existing value.

This PR modifies AttributesMap.put to search for any existing key with the same string representation and remove it before inserting the new key/value. It also overrides putAll to ensure all entries are processed through put to correctly deduplicate and respect the capacity limits.

Checklist

• Added unit tests verifying last-value-wins behavior with different types in AttributesMapTest
• Code formatted using spotlessApply

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.14%. Comparing base (32440c1) to head (4c3817a).

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #8420      +/-   ##
============================================
- Coverage     91.14%   91.14%   -0.01%     
- Complexity     7761     7766       +5     
============================================
  Files           881      881              
  Lines         23409    23421      +12     
  Branches       2331     2334       +3     
============================================
+ Hits          21337    21346       +9     
- Misses         1377     1378       +1     
- Partials        695      697       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

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

[psx95]

Based on the the previous discussion around this issue in this comment, I would recommend running benchmark tests to ensure that this implementation is at least as performant as existing code.

Additionally, it looks like this issue warranted a larger change about replacing extends HashMap with a custom implementation that uses a custom map that stores attributes by raw string key.