feat(bindings/cpp) remove lib.rs.h from opendal.hpp

[deadlinefen]

Which issue does this PR close?

nop, but inspired by the discussion #6035

Rationale for this change

Remove lib.rs.h from opendal.hpp to make the included source files cleaner for users.

What changes are included in this PR?

• Using type erasure to remove lib.rs.h from opendal.hpp, but note that this will introduce an additional pointer access overhead, we will fix this in the future.
• Replace macro definitions with template functions to convert C++ containers into Rust containers.
• Change the return type of operator::read from vector<uint8_t> to string.
• Rename Lister::ListerIterator to Lister::Iterator to eliminate naming redundancy.

Are there any user-facing changes?

• Change the return type of operator::read from vector<uint8_t> to string. Since the C++ binding hasn't been officially released yet, I think this change should be acceptable.
• This helps minimize the code expansion when users include opendal.hpp during preprocessing.

cc @JackDrogon

[Xuanwo]

A quick question: std::string is a bytes or an UTF-8 string? Please note that opendal's read returns a bytes, aka, Vec<u8>.

[deadlinefen]

A quick question: std::string is a bytes or an UTF-8 string? Please note that opendal's read returns a bytes, aka, Vec<u8>.

std::string differs from Rust's String: it's ​a byte container without encoding validation, where size() returns the ​byte length (length of raw binary data, not character count).

[Xuanwo]

std::string differs from Rust's String: it's ​a byte container without encoding validation, where size() returns the ​byte length (length of raw binary data, not character count).

Thank you for the explanation.

[Xuanwo]

CI failed for:

2025-04-17T06:19:21.909558+00:00[Etc/UTC] ERROR hawkeye::subcommand: subcommand.rs:110 Found missing header files: ["/home/runner/work/opendal/opendal/bindings/cpp/src/details/common.hpp", "/home/runner/work/opendal/opendal/bindings/cpp/src/details/operator.cpp"]

[JackDrogon]

LGTM!

[Xuanwo]

Thank you for working on this, @deadlinefen and @JackDrogon!