Fix mvnup plugin upgrade for plugins inherited in build/plugins

[gnodet]

Summary

• When a remote parent POM declares a plugin with an explicit version in <build><plugins> (not <pluginManagement>), mvnup's plugin upgrade strategy now adds the plugin to both <pluginManagement> and <build><plugins> in the child project
• Previously, only a <pluginManagement> entry was added, which is insufficient because the parent's <plugins> version takes precedence over the child's <pluginManagement>
• This fixes the scenario described in the ratis-hadoop-projects issue where maven-enforcer-plugin:1.4.1 inherited from a parent's <plugins> section caused NoSuchMethodError in Maven 4

Test plan

• New test shouldAddDirectBuildPluginsOverrideForInheritedPlugins verifies both pluginManagement and build/plugins entries are added for inherited plugins
• New test shouldNotDuplicatePluginInBuildPluginsWhenAlreadyDeclared verifies no duplicates when plugin is already locally declared
• All 29 existing + new PluginUpgradeStrategy tests pass

🤖 Generated with Claude Code

[gnodet]

Claude Code on behalf of Guillaume Nodet

Closing in favor of a more precise implementation that only adds direct <plugins> entries when the parent's version is truly locked (explicit version in <plugins>, not from <pluginManagement>). The previous approach added unnecessary <plugins> entries even when a <pluginManagement> override alone would suffice.

[gnodet]

Claude Code on behalf of Guillaume Nodet

Superseded by #12165, which uses a more precise approach — comparing effective versions in build/plugins vs build/pluginManagement/plugins upfront to determine the correct override location, avoiding unnecessary <plugins> entries.