Fix: support custom <message> output for 9 enforcer rules that ignored getMessage()

[btpka3]

Problem

Several enforcer rules did not output the user-configured <message> when
the rule failed. This meant users could not provide custom context or
explanations for rule violations.

For example, with this configuration:

<bannedPlugins>
  <message>Please remove the deprecated plugin before migrating.</message>
  <excludes>
    <exclude>com.example:old-plugin</exclude>
  </excludes>
</bannedPlugins>

The custom message was silently ignored and only the default error details were shown.

Solution

Follow the existing pattern (already used by AlwaysFail, BannedDependenciesBase, etc.)
to prepend getMessage() to the error output when set:

StringBuilder buf = new StringBuilder();
if (getMessage() != null) {
    buf.append(getMessage()).append(System.lineSeparator());
}
buf.append("default error details...");
throw new EnforcerRuleException(buf.toString());

Fixed Rules (9 total)

Rule	Problem
BannedPlugins	Threw result directly, never checked getMessage()
BannedRepositories	Threw errMsg directly
BanDuplicatePomDependencyVersions	No message prefix
BanDistributionManagement	Inner class threw directly, outer never wrapped
RequireMatchingCoordinates	No message prefix
RequireExplicitDependencyScope	No message prefix
RequireProfileIdsExist	No message prefix
RequireSameVersions	No message prefix
RequirePrerequisite	Used replacement pattern instead of prepend

Tests

All 9 modified rules now have test coverage verifying the custom message is correctly prepended:

Test File	Status
TestBannedPlugins	New (4 tests)
TestBannedRepositories	Added shouldOutputCustomMessageWhenBanned
TestRequireSameVersions	Added shouldOutputCustomMessageWhenVersionsDiffer
BanDistributionManagementTest	Added shouldOutputCustomMessageWhenBanned
RequirePrerequisiteTest	Added shouldOutputCustomMessageWhenPrerequisiteNotSet
TestRequireExplicitDependencyScope	New
TestRequireProfileIdsExist	New
TestRequireMatchingCoordinates	New (2 tests)

All 259 tests pass with mvn -pl enforcer-rules test.

Checklist

• Your pull request should address just one issue, without pulling in other changes.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Each commit in the pull request should have a meaningful subject line and body.
• Write unit tests that match behavioral changes.
• Run mvn verify to make sure basic checks pass.
• You have run the integration tests successfully (mvn -Prun-its verify).

ICLA

ICLA has been submitted to secretary@apache.org and is pending approval.

• I hereby declare this contribution to be licenced under the Apache License Version 2.0, January 2004