Add ignoreOptionals option to bannedDependencies and requireReleaseDeps - #1078

LGTM — this closes a real gap, and thanks for handling the release-notes half separately.

I checked the thing that worried me, and it holds: the flag means the same thing in both modes. searchTransitive=false filters getDependencyArtifacts() with !(ignoreOptionals && a.isOptional()), and searchTransitive=true hands it to ResolverUtil.resolveTransitiveDependencies(…, excludeOptional, …), which filters project.getDependencies() with the identical predicate. Same scope — direct dependencies of the project — so there is no mode where the parameter surprises you. Default false keeps the 3.7.0 behaviour, which seems right.

I also like that banned-dependencies-fail was extended to assert that the transitive of an optional is banned. That pins the 3.7.0 behaviour which caused #1077, so a regression in either direction gets caught.

Verified locally on d4ec185: enforcer-rules green at 303 tests.

One non-blocking suggestion: the new banned-dependencies-ignore-optionals IT has no assertion. It contains only pom.xml — no verify.groovy (71 of the 117 IT projects have one, and its sibling banned-dependencies-fail does). It does discriminate on the feature, since a broken ignoreOptionals would ban menforcer138_io and fail the build; but it passes on "build succeeded", so it would also pass if the enforcer execution never ran at all. Two lines would close that:

def buildLog = new File( basedir, 'build.log' ).text
assert !buildLog.contains( 'banned via the exclude/include list' )

And two cosmetic notes, take or leave:

• The rule parameter is ignoreOptionals while the resolver method it delegates to calls the same concept excludeOptional — two names for one thing in the same package.
• The site docs say "optional dependencies of the project (and their transitive dependencies)"; the PR description more precisely says direct optional dependencies. Adding "direct" would stop a reader expecting optionals to be skipped anywhere in the tree.