Fix #4270: preserve Qt property accessor references for unusedFunction

[tzi4]

This fixes the false unusedFunction warnings reported in Trac #4270. Cppcheck can report a method as unused even when it is referenced by Q_PROPERTY, because the Qt configuration removes the declaration during preprocessing.

The patch keeps those references through macro expansion using Qt's QT_ANNOTATE_CLASS hook and passes them to the unused function check. I added tests for wrapper macros, inherited accessors and cached results. I also checked that unrelated unused methods still produce a warning.

All 46 new integration cases pass, along with Cppcheck's full C++ test suite.

I also tried a few property examples with Qt 5 and Qt 6.11.2 moc, and both generated the expected accessor calls.

[danmar]

This is an AI review. Take it with a grain of salt and feel free to reject it by resolving the comment.

I built the PR and confirmed the ticket example: value/setValue/resetValue/name referenced from Q_PROPERTY are no longer reported, while a really unused method still is. The 60 tests in test/cli/unused_function_test.py pass.

Design question: qtPropertyAttributes() + qtPropertyFunctions() hard-code Qt's grammar (type parsing with templates/>>, CONSTANT/FINAL/REVISION/MEMBER, ...) in the generic Preprocessor, and they are the only reason preprocessor.cpp now includes token.h (for Token::isStandardType), which pulls in many headers (see the oss-fuzz/Makefile diff). The <exporter prefix=...> list in qt.cfg already describes what matters.

As an experiment, I replaced qtPropertyFunctions() with the generic rule "a name (optionally ::-qualified or parenthesized) following an exporter prefix keyword at depth 0". All but 4 of the 60 CLI tests still pass. The 4 failures are all test_unused_functions_qt_property_keyword_names, where a type or the property itself is named READ/WRITE (class READ {}; Q_PROPERTY(READ property READ value ...)). Is handling such names worth around 60 extra lines of Qt-specific parsing in the preprocessor? In that rare case the worst outcome is that a function named like the type is treated as used. With the generic rule, qtPropertyAttributes() and the token.h include could go away, and the same code could serve any library exporter, not just Q_PROPERTY.