Add tests to reproduce #5152 (Support iPhone properties)

[JooHyukKim]

Fixes #5152

[JooHyukKim]

Needs discussion

Surprisingly setting default to true does not break anything so I figured enable by default in Jackson 3.

[Copilot]

Pull Request Overview

Adds support for mixed-capitalization property names (e.g. iPhone) by introducing a new naming feature and corresponding logic.

• Introduces MIXED_CAPS_PROPERTY_NAMING in MapperFeature
• Refactors naming in DefaultAccessorNamingStrategy via handlePropertyName and adds mixedCapsManglePropertyName
• Adds IPhoneStyleProperty5152Test with cases for iPhone, dLogHeader, and KBSBroadCasting

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
src/main/java/com/fasterxml/jackson/databind/MapperFeature.java	Adds MIXED_CAPS_PROPERTY_NAMING enum constant with doc describing its behavior
src/main/java/com/fasterxml/jackson/databind/introspect/DefaultAccessorNamingStrategy.java	Refactors per-accessor naming into handlePropertyName and implements mixed-caps logic
src/test/java/com/fasterxml/jackson/databind/introspect/IPhoneStyleProperty5152Test.java	New tests for mixed-cap property naming

Comments suppressed due to low confidence (1)

src/main/java/com/fasterxml/jackson/databind/introspect/DefaultAccessorNamingStrategy.java:257

• The branch for preserving case when more than two uppercase letters is not covered by existing tests; consider adding a unit test for a method like getURL to ensure original casing is preserved.

int upperCount = 2; // We already know first two are uppercase

[cowtowncoder]

Ok, quick note: this is not quite along the line I think it could be made to work.
I don't think it is possible to change name mangling from getter/setter to produce exactly matching field name. Forgetting about specific "iPhone", method like getPhone() could match either of:

public String phone; // more common, maps by default from `getPhone()`
public String Phone; // would also map to `getPhone()`

but expecting different logical name in JSON ("phone", "Phone") and so there won't be a reliable way to support various alternatives when starting mangling from accessor names.
Starting from field name would, on the other hand would require too big internal API changes to work although it might otherwise be possible.
So, instead, I think it is post-processing incompatible candidates that would work, in POJOPropertiesCollector.

Be that as it may, what could be useful as the starting would be creating a set of failing tests, under ".tofix". I think we can agree on cases that should work.

[cowtowncoder]

No, these are not valid test cases: these will require annotations (like @JsonProperty) to be recognized as valid; they will not be auto-detected.

Issue #5152 is specifically about case differences. If there is desire to try to support non-letter-starting property names, let's file different issue.

[cowtowncoder]

Interestingly, testKBSBroadCastingStyleProperty() passes on 3.0. No idea why/how.