Implement Java-backed DBM support for dbmopen and dbmclose

The issue requires implementing dbmopen and dbmclose operators in CoreOperatorResolver, using SQLite JDBC as the storage backend. Start by examining the existing parser and operator resolver in the PerlOnJava codebase, then create a Java module (likely PerlOnJava::DBM) to handle tied-hash operations. Write unit tests in src/test/resources/unit to verify DBM behavior, and ensure compatibility with JVM and interpreter backends. The work is done when the relevant perl5_t DBM tests pass without modifying upstream tests.

Summary

Implement Java-backed DBM support for PerlOnJava so portable Perl programs can
use dbmopen and dbmclose without XS modules such as DB_File, SDBM_File,
NDBM_File, or GDBM_File.

The current parser recognizes the operators and their Perl prototypes, but
CoreOperatorResolver deliberately throws Not implemented: operator: dbmopen
and dbmclose. AnyDBM_File therefore cannot select a usable backend under
PerlOnJava.

Motivation and evidence

The Perl core tests perl5_t/t/op/dbm.t and the DBM portions of
perl5_t/t/op/coreamp.t currently cannot run:

Not implemented: operator: dbmopen at op/dbm.t line 67, near "(%truffe"

The upstream tests exercise observable tied-hash behavior, but the standard
Perl implementations are native XS modules. PerlOnJava should provide a
portable Java implementation for the common DBM contract rather than attempt
to load those native modules.

Proposed first implementation

Use the already bundled SQLite JDBC dependency as the storage engine. Store
byte-string keys and values in a table keyed by the DBM filename, with a
schema equivalent to:

CREATE TABLE entries (
    key BLOB PRIMARY KEY,
    value BLOB NOT NULL
)

Expose the backend through a PerlOnJava Java module, likely a
PerlOnJava::DBM implementation registered through XSLoader, and provide a
minimal Perl-side SDBM_File/AnyDBM_File compatibility layer as needed.

The first format need not read or write legacy Berkeley DB, SDBM, NDBM, or GDBM
files. It should document that the initial backend is PerlOnJava-native. A
future compatibility layer can be considered separately.

Required behavior

Implement and test:

• dbmopen(%hash, $filename, $mode);
• dbmclose(%hash);
• tied-hash FETCH, STORE, DELETE, CLEAR, and EXISTS;
• FIRSTKEY/NEXTKEY iteration with stable behavior during a scan;
• read-only versus writable open modes;
• creation and reopening of persistent databases;
• empty values, binary keys, and binary values;
• missing-file and invalid-mode diagnostics;
• close/untie cleanup and transaction commit behavior;
• file locking or an explicit documented concurrency boundary;
• consistent behavior on JVM and interpreter backends;
• useful $!/Perl exception behavior for filesystem and SQLite failures.

Compatibility boundaries

The first version should not claim compatibility with existing native DBM file
formats. It should also avoid silently pretending that DB_File, GDBM_File,
NDBM_File, ODBM_File, or SDBM_File XS APIs are available. Existing
XSLoader unsupported-module handling must remain explicit and predictable.

coreamp.t contains unrelated given/when coverage, so DBM work alone will
not make that entire core test pass. The DBM-specific assertions should be
covered independently.

Testing and acceptance criteria

• Add project-owned unit tests under src/test/resources/unit for the complete
  supported DBM behavior.
• Validate each Perl-level test with system Perl where the behavior has a
  standard-Perl representation.
• Require JVM and interpreter backend success.
• Add persistence, iteration, binary-data, read-only, cleanup, and error-path
  coverage.
• Run the relevant perl5_t DBM tests when the implementation is complete,
  without modifying upstream tests.
• Update compatibility documentation and the unsupported-feature notes to
  state the supported backend and file-format boundary.
• Keep the implementation independent of platform-specific native DBM
  libraries.