Public headers require C++23, forcing the same on every consumer

`CMakeLists.txt:35` sets `CMAKE_CXX_STANDARD 23`, which is a fine choice for the
library's own sources. The requirement is not confined to them, though.
`src/iceberg/result.h` includes `` and ``, and defines:

```cpp
template ::type>
using Result = std::expected;

using Status = Result;
```

`Result` is the return type of most public entry points —
`Catalog::ListNamespaces`, `ListTables`, `LoadTable`, `CreateTable`,
`StageCreateTable` and so on. Every consumer translation unit that calls them
must therefore compile as C++23 as well. `std::expected` needs libstdc++ 12 or
libc++ 16 and `` needs libstdc++ 13, so a consumer on an older but still
widely deployed toolchain cannot include the headers at all.

This matters for the engines the library is meant to be embedded in: Velox
builds as C++20, Arrow as C++17, DuckDB as C++11. Integrating leaves two
options — move the whole engine to C++23, or add an isolation layer whose only
purpose is keeping iceberg-cpp headers out of the rest of the build. We are
looking at iceberg-cpp for an Iceberg connector in
[Axiom](https://github.com/facebookincubator/axiom), which builds on Velox at
C++20, and would rather do neither.

Would you consider making the public error type portable while keeping the API
shape unchanged?

```cpp
#if defined(__cpp_lib_expected)
template ::type>
using Result = std::expected;
#else
// vendored fallback with the same interface
#endif
```

`arrow::Result`, `absl::StatusOr` and `tl::expected` all exist for this reason.
The library's own sources could keep building as C++23; only the public headers
would need to hold a lower baseline.

Happy to send a patch if the direction is agreeable.

cc @PingLiuPing, who is proposing the Iceberg connector for Axiom.

Bắt đầu với CMakeLists.txt:35 và header công khai src/iceberg/result.h, sau đó lần theo các điểm vào Catalog được liệt kê có cung cấp Result. So sánh các tính năng thư viện C++23 cần thiết với những toolchain cũ hơn được nêu trong issue. Công việc được coi là hoàn tất khi người dùng có thể include và sử dụng API công khai mà không cần áp dụng C++23, trong khi mã nguồn của chính thư viện vẫn có thể tiếp tục được build dưới dạng C++23 và cấu trúc API không thay đổi.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.