Export-macro recovery: project-level override for the candidate rule (follow-up to #2005)

[DeusData]

Follow-up to #2005 (refs #1989), which recovers C/C++ type definitions hidden behind build-system export macros (class MOD_API Foo, UE's MODULE_API, CMake's <lib>_EXPORT) by detecting candidate macro names from a built-in shape rule — identifiers ending in _API / _EXPORT / _IMPORT / _DLLEXPORT / _DEPRECATED with a prefix of at least two characters, at most 32 per file — and defining them empty in the preprocessing second pass.

That heuristic was accepted as the zero-config default (it is what most real codebases need and it costs users nothing). What is missing is the explicit path the original report called option 2: a way for a project to override the rule when the shape rule is wrong for it.

Scope of the ask:

• add project-level configuration to extend the candidate set with explicit export-macro names (or additional suffixes) that the shape rule does not match — e.g. a project whose export macro is EXPORTED or PUBLIC_SYMBOL;
• add the matching way to exclude a name the rule matches but that is a genuine symbol in that project (the one known failure mode: an all-caps identifier with one of those suffixes used as a real symbol would be defined empty for that file);
• keep the precedence fix(parsing): recover export-macro-hidden type definitions (#1989) #2005 already established — explicitly configured defines always win over inferred ones;
• document it next to the existing preprocessing/defines configuration; tests for extend, exclude, and precedence.

Not a blocker for #2005 — this is the escape hatch on top of it. @XIYBHK, since you know this code best now: would you like to take it? No pressure on timing.