Add Pipeline for /eng/code-quality-reports

[alzimmermsft]

Description

Fixes #26140

This PR adds a new pipeline for /eng/code-quality-reports, referred to as linting pipeline, that is ran any time a change is made to linting tooling and configuration. The new pipeline will build all libraries that use azure-core, directly or in it's dependency graph, and run Checkstyle, RevApi, and Spotbugs against the built libraries. This resolves a gap in coverage where previously changes to eng/code-quality-reports would only run the Core pipeline and this pipeline only runs linting validation for the Core libraries. So, unfortunately there is/was a gap in validating linting changes which had caused unexpected linting errors to occur in other SDK groups as they weren't validated. Additionally, now changes made to eng/code-quality-reports will no longer trigger the Core pipelines (which are generally expensive in terms of validation time).

A few additional changes were made to the parent POM to enable this change. Now there are more configuration points in the POM which allow enabling/disabling Checkstyle, RevApi, and Spotbugs to fail on errors reported. This was done as the linting pipeline should validate all libraries completely ignoring any failures and use a post-processing check to determine if the pipeline should be failed (based on any linting error reports existing). There is also a linting error report processor being added as both Checkstyle and Spotbugs use XML which are human readable but it was determined a CSV would be easier for consumption.

In the future, changes made in this PR have made it easier to allow for parallel processing of linting reports. Currently, these are done synchronously as the CLI output is being used in most places to troubleshoot and resolve linting errors found during CI.

All SDK Contribution checklist:

• The pull request does not introduce [breaking changes]
• CHANGELOG is updated for new features, bug fixes or other significant changes.
• I have read the contribution guidelines.

General Guidelines and Best Practices

• Title of the pull request is clear and informative.
• There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

• Pull request includes test coverage for the included changes.

[alzimmermsft]

/azp run prepare-pipelines

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[weshaggard]

I think there might be other paths like eng/common we want to add to this list as well.
cc @benbp @hallipr