Avoid loading XML files for default SQL exception translation

[wilkinsona]

#25335 allowed the use of SQLErrorCodeSQLExceptionTranslator to be disabled by configuring spring.ignore.xml to true. This successfully reduced the footprint when running in a GraalVM native image, but at the cost of potentially different exception translation. To ensure consistent behavior, it would be useful if SQLErrorCodeSQLExceptionTranslator could be used without loading sql-error-codes.xml.

From @jhoeller:

For our default purposes, we could even keep those error code mappings in a hard-coded class - and possibly get rid of the default sql-error-codes.xml file completely, just supporting that file format for user-provided files.

[jhoeller]

On further consideration, I'm inclined to align with our R2DBC support and just rely on JDBC-provided exception subclasses by default, potentially with a few database-specific checks attached (like we do for ResultSet value extraction), and with the ability to customize the behavior programmatically (which we effectively have already but could provide more specific hooks for).

In other words, we would consistently not use explicit error code definitions by default anymore (not XML-provided and no hard-coded equivalent either) since they effectively duplicate indications in the JDBC 4 exception subclasses to quite some degree. With modern-day JDBC drivers on a JDK 17 baseline, there should be no need for such a full-scale replacement, rather just for a few specific database-specific adaptations within the JDBC exception subclass indications.

We may keep SQLErrorCodeSQLExceptionTranslator for user-provided sql-error-codes.xml files, triggered by the presence of such a file in the root of the classpath. However, we would not ship a default XML file ourselves anymore. For anyone inclined, they could be copying our current sql-error-codes.xml file to their classpath for strict backwards-compatible behavior. That said, I'd rather like to hear from every such case about why they need any explicit error code mappings to begin with, considering some database-specific tweaking of our SQLExceptionSubclassTranslator based on that feedback instead.