Improve mapper resource failure diagnostics

[DragonFSKY]

Summary

• Report mapper resource opening failures separately from XML parsing failures.
• Provide an actionable hint to resolve wildcard locations with ResourcePatternResolver.getResources() before calling setMapperLocations(...).
• Add regression coverage for unresolved patterns, correctly resolved resources, and malformed mapper XML.

Motivation

Issue #792 shows that passing the result of getResource(...) for a wildcard location fails later when SqlSessionFactoryBean opens the resource. The existing catch block classified that I/O failure as an XML parse failure, so the exception did not explain how to correct the configuration.

Following the maintainer guidance in #792, this change updates the exception at the actual I/O failure site rather than documenting an exception on the setter, which performs no I/O.

Implementation

• Open each mapper resource in a dedicated try/catch block and preserve the original cause.
• Keep XMLMapperBuilder construction and parsing under the existing parse-failure diagnostic.
• Preserve ErrorContext reset behavior.

Verification

• ./mvnw verify
• BUILD SUCCESS — 226 tests, 0 failures, 0 errors, 15 skipped

Closes #792

[coveralls]

coverage: 90.616% (+0.2%) from 90.381% — DragonFSKY:fix/issue-792-mapper-resource-diagnostics into mybatis:master