Support preserving original package when remapping illegal names

[JamesBraver]

• Add mapClass(info, mapPackage) to NameGenerator to control package remapping.
• Implement package-aware naming in AlphabetNameGenerator and IncrementingNameGenerator.
• Introduce shouldMapPackage in NameGeneratorFilter and all filter implementations to decide whether a class's package should be remapped.
• Update MappingGenerator and IllegalNameMappingTransformer to use the new package mapping logic.
• Fix argument order in getMappedFieldName/getMappedMethodName calls within IllegalNameMappingTransformer.
• Add tests verifying that illegal class names are remapped while keeping legal packages intact.

What's new

• I don't know.

What's fixed

• I don't know.

[Col-E]

I agree that there should be a way to keep the original package if the package name is fine and just the local class name is messed up, but I don't think adding an explicit carve-out for this use case serves as the best approach. Having a shouldMapPackage conflicts with shouldMapClass because what if you have package = true but class = false? Is it just used to tie into the final incrementing renaming scheme? The incrementing name generator should take in some parameters or config model for this and handle it locally without forcing all other name generators to fit this one's implementation shape.