Add suport for wrapped_compact_tuple_sketch

[SavicStefan]

Summary

This PR adds wrapped_compact_tuple_sketch, a non-owning view over a
serialized compact tuple sketch. It follows the same model as
wrapped_compact_theta_sketch: callers can use a serialized sketch without
materializing all retained entries in an owning vector.

How it works

• wrap() validates the header, sketch type, family, seed hash, metadata,
  and complete serialized payload.
• The wrapper stores parsed metadata and pointers to the entry range. The
  caller must keep the serialized buffer alive.
• Its input iterator deserializes one {hash, summary} entry at a time into
  aligned in-place storage.
• A common base_tuple_sketch provides APIs shared by materialized and
  wrapped_compact_tuple_sketch.
• Compact sketch construction and tuple set operations can consume the
  wrapped representation.

This avoids memory use proportional to the retained-entry count. Fixed-
width summaries require no heap storage for entries. Variable-width
summaries, such as strings, may still allocate internally, but the wrapper
materializes only one entry at a time.

Tests

Tests cover:

• Empty, exact-mode, and estimation-mode sketches
• Variable-width summaries
• Malformed, truncated, and trailing input
• Tuple set operations
• Allocation-free iteration for fixed-width summaries

[SavicStefan]

@apache/datasketches-committers
Hi guys, what do you think about this API change for the tuple sketch, this is match theta sketch impl? Thank you.

P.S Sorry for not doing this properly via mailing list, but I saw in last PR that no one responded via it.

[proost]

This PR moves existing virtual methods into base_tuple_sketch and inserts print_items before the iterator methods in the virtual layout. So This makes ABI breaking change.

Normal full recompilation will generally work because the project is header-only, but objects crossing shared-library/plugin boundaries are ABI-incompatible.

[leerho]

@SavicStefan,
Please respond to @proosts comment. We will be undergoing a major refactoring of the C++ library soon and if this PR isn't addressed I will have to close it. Then after the refactor you will have to update this PR to the new structure before opening it again.

[leerho]

I am closing this PR. There has been no response on this PR for nearly a month. We are preparing for some major releases and if the author feels that it is important it can be reopened later.