fix diameter symbol missing [PDFBOX-5960]

[valerybokov]

The bug: PDFBOX-5960 (https://issues.apache.org/jira/browse/PDFBOX-5960) is a regression (2.0.33+/3.0.4, worked in 1.8.16) where a diameter symbol fails to render. The attached font (ASCON HPDFAA+Symbol_A, from a "KOMPAS" export) has a malformed FontDescriptor where both the Symbolic (4) and NonSymbolic (32) flag bits are set — contradictory. It also has an /Encoding dictionary with /BaseEncoding /StandardEncoding and a /Differences array mapping code 71 > /Ccedilla.

PDTrueTypeFont.isSymbolic() trusted the raw Symbolic bit and took the "symbolic" code path, looking up glyph 71 directly through the font's (3,0) cmap — landing on GID 34 (post name "G", visually wrong). The correct glyph (the diameter symbol) is GID 90, reachable only by resolving the /Differences name "Ccedilla" through the post table, the way a non-symbolic font would.

The fix (pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/PDTrueTypeFont.java): in codeToGID(), when the descriptor has contradictory flags and the Encoding dictionary has a recognized /BaseEncoding, resolve by glyph name first, falling back to the existing code-based cmap logic only if that yields GID 0. Ordinary symbolic fonts (the common case) are untouched.

---

Test: #522

Per https://www.apache.org/legal/generative-tooling.html: portions of this PR were
produced with assistance from Claude Code (Anthropic), based on a bug was described in Apache PDFBOX Issue Tracker.

I've reviewed the generated code and confirm to the best of my knowledge that the output does not include any
third-party copyrighted material and is compatible with the Apache License 2.0.

[THausherr]

Thank you, this looks good. I'll do that change in two steps, first refactoring that big code chunk into the new codeToGIDByName() method and then the actual change. This way it will be more clear in the history what was done.