[core] Remove config errors

Is your feature request related to a problem? Please describe.
We currently have a type ConfigError that is supposed to be part of Report objects. This has very limited usefulness for now. Only a couple of rules actually do some validation that can end up as a config error. Validation of properties in the XML does not, for instance. Config errors are badly supported by renderers (#194) and by pmd integrations like the maven plugin (quoting #1371). They're ignored almost everywhere.

I think "configuration errors" are a superflous concept that we shouldn't support at all. A configuration error is an error in the user-supplied configuration of PMD, eg invalid properties or invalid classpath. There is conceptually no difference between this and eg validating command line arguments. Currently a lot of validation is done in PMD by logging a message, and throwing an exception and letting the calling code catch it. Comparatively few places have access to a report and we couldn't transform everything to put config errors into a report. Nor would this be sensible: what good would a report be that only has one error because we couldn't continue executing the program.

Describe the solution you'd like

I think we should

• improve on our logging facilities, but not use a report as the output of our errors and diagnostic warnings about configuration. We just need to distinguish recoverable and fatal errors. A wrong auxclasspath is recoverable, and we can log a warning about it which will prompt the user to fix their configuration. Wrong properties could actually be treated as non-recoverable: we already do it for non-existent properties, so why does LooseCoupling create a ConfigError for what is the same kind of error?
• Remove ConfigErrors from the codebase and from Report

Describe alternatives you've considered

Additional context

• Related to #3816
• Related to #3761
• Replaces #194
• Related to #3914
• Related to #1371
• Related to #3868

Start by locating ConfigError and its integration with Report, then trace the related configuration validation and logging paths mentioned in the issue. Done means removing ConfigError from the codebase and Report while establishing the proposed handling for recoverable and fatal configuration errors; no specific files or tests are named.