I have provided .rubocop-pom.yml for future cleanup or auditing. Latest commit disables it in a couple of key places and makes a couple other small tweaks to get mvn deploy -Psnapshots to run (which should touch just about all pom.rb files). Tests are green.

I have only enabled one additional cop: Style/StringHashKeys to clean up hashes and keyword argument calls that still used strings. Some of these strings were not naturally "symbolable" (e.g. "Automatic-Module-Name") but the consistent use of key: value format looks much cleaner.

The other tweaks involved two changes:

• Modify a [] call to a now-symbol-based Hash to use a symbol key instead of a string key (RuboCop does not catch this).
• Reference the top-level Gem constant using ::Gem when reopening it to access extension builder logic. I'm not sure why this was necessary since it doesn't seem like any of the RuboCop changes should have broken it. cc @enebo for any thoughts since we've been playing with top-level constant resolution fixes a bit over the last few months.

Reference the top-level Gem constant using ::Gem

This turned out to be an unsafe correction by RuboCop, due to the difference in behavior from path-based module reopening versus nested module reopening. I've filed rubocop/rubocop#14476 and disabled that cop for the line in question (leaving it as a path).