Demo implementation of minimal Java & .Net support and C language bindings

[jamesblackburn]

Language Bindings: Java (Panama FFM) & .NET (P/Invoke) via C API

This PR makes ArcticDB's read path accessible from Java and .NET through a
stable C shared library (libarcticdb_c.so) and the Arrow C Stream Interface.

What's new

C API layer (cpp/arcticdb/bindings/)

A extern "C" API with opaque handles and fixed-size error structs, designed to
be consumed from any language with FFI support:

• arctic_library_open_lmdb / arctic_library_close — library lifecycle
• arctic_read_stream — streaming reads via ArcticArrowArrayStream (wraps
  LazyRecordBatchIterator)
• arctic_list_symbols / arctic_free_symbols — symbol enumeration
• arctic_write_test_data — synthetic data for integration testing

The read path replicates
PythonVersionStore::create_lazy_record_batch_iterator_with_metadata() in pure
C++ — no Python at runtime. Data is delivered as Arrow record batches through
the standard get_schema() / get_next() / release() consumption pattern.

Java bindings (java/)

Uses Java 21's Panama FFM API (preview) — no JNI, no generated code:

• ArcticNative.java — struct layouts (MemoryLayout.structLayout), method
  handles via Linker.downcallHandle(), function pointer invocation for Arrow
  callbacks
• ArcticLibrary.java — AutoCloseable high-level wrapper returning ReadResult
  records
• Library loading via dlopen(RTLD_LAZY) through FFM to defer resolution of
  unused Python symbols

.NET bindings (dotnet/)

Uses standard P/Invoke with .NET 8:

• ArcticNative.cs — DllImport bindings, StructLayout structs,
  DllImportResolver for library path
• ArcticLibrary.cs — IDisposable high-level wrapper,
  Marshal.GetDelegateForFunctionPointer() for Arrow callbacks
• ArcticException for structured error propagation

Implementation decisions

Link order fix for libarcticdb_c.so: arcticdb_core_static and AWS SDK .a files
are duplicated on the linker command to work around glibc's single-pass
static archive resolution. Without this, AWS symbols referenced by the core
library were unresolved.

Python symbol resolution: arcticdb_core_static contains pybind11 code with
static constructors that reference Python symbols at dlopen time — even though
the C API never calls Python at runtime. We link libarcticdb_c.so against
Python3::Python to satisfy these references. Long-term, separating the core
engine from Python binding code in CMake would eliminate this dependency.

Java lazy loading: Java's System.load() uses RTLD_NOW, which fails on any
unresolved symbols. The Java bindings call dlopen directly via FFM with
RTLD_LAZY, then wrap the handle in a SymbolLookup backed by dlsym. This
cleanly avoids the Python symbol issue without requiring LD_PRELOAD hacks.

Arrow struct layouts: Hand-defined to match the x86_64 Linux ABI — ArcticError
(516 bytes), ArcticArrowArrayStream (40 bytes, 5 pointers), ArrowSchema (72
bytes), ArrowArray (80 bytes). Both Java and .NET define these identically.

Test coverage

10 integration tests (5 per language), all passing:

Documentation

• Developer: docs/claude/cpp/C_BINDINGS.md — C API surface, Arrow stream
  consumption pattern, Java/dotnet binding details, design decisions
• User-facing: docs/mkdocs/docs/tutorials/language_bindings.md — setup, usage
  examples, and test commands for both languages
• Architecture: docs/claude/ARCHITECTURE.md — updated diagram and module
  tables

Further work

• S3/Azure backends — add arctic_library_open_s3() /
  arctic_library_open_azure() to the C API
• Arbitrary writes — expose a write API beyond the test helper (accepting
  Arrow arrays)
• Raw Arrow array access — expose full ArrowArray data to callers (not just
  summary ReadResult)
• NuGet/Maven packages — publish bindings as proper packages with bundled
  native library
• Windows/macOS — build and test libarcticdb_c on other platforms
• Separate core from Python in CMake — eliminate the Python3::Python link
  dependency by splitting arcticdb_core_object into Python-free and
  Python-dependent targets