feat(gRPC)!: improve client ergonomics & read-mask discoverability

[DaughterOfMars]

Follow-up to the initial gRPC client landing (#1062). This PR sharpens the
high-level Rust gRPC API around two recurring rough edges — every read method
having to take an Option<ReadMask>, and callers having to know by convention
which XField namespace pairs with which method — and adds a handful of
examples that exercise the result.

Summary

• Split every masked endpoint into a default-mask method + a _masked
  variant. client.get_objects(refs) uses the canonical default mask;
  client.get_objects_masked(refs, mask) takes a mask directly (no
  Option, no wrapper). Applied to all 17 masked methods across
  get_objects / get_objects_with_versions / get_transactions /
  get_service_info / get_epoch / get_checkpoint_* / stream_checkpoints*
  / list_owned_objects / list_dynamic_fields / get_coins /
  simulate_transaction(s) / execute_transaction(s).
• Typed scoped read masks per endpoint. Each XField (e.g.
  ObjectField, TransactionField, EpochField, …) is now a typed
  Cow<'static, str> newtype instead of a bag of &str consts, and each
  masked endpoint accepts a paired XReadMask (ObjectReadMask,
  TransactionReadMask, …) via impl Into<…>. Call sites become:

  client.get_objects_masked([id], ObjectField::BCS).await?;
  client.get_objects_masked([id], [ObjectField::REFERENCE, ObjectField::BCS]).await?;

  No ReadMask::from(…) wrapper. Passing TransactionField::EFFECTS to
  get_objects_masked is now a compile error. Pre-computed mask constants
  in read_masks::* still flow through via From<&'static str> /
  From<String> escape hatches on each scoped mask.
• New Client::get_coins(_masked) plus GetCoinsQuery builder in
  state/coins.rs — paginated coin listing with optional StructTag
  filter, returning iota_types::framework::Coin items (proto Object →
  SDK Coin conversion happens internally).
• CheckpointResponse accessors refactored to return SDK types directly.
  response.summary() / .signature() / .contents() now yield the
  deserialized SDK types; the proto variants are renamed to _grpc
  (summary_grpc, etc.). Same pattern as the executed_transactions /
  executed_transactions_grpc split.
• Network constructors on Client: Client::new_localnet(),
  new_devnet(), new_testnet(), new_mainnet() plus pub-crate host
  constants.
• TLS features forwarded from iota-sdk's grpc feature. Previously
  enabling iota-sdk/grpc pulled in iota-grpc-client with
  default-features = false, so Client::new_testnet() failed at runtime
  with "HTTPS requires the tls-ring feature". The grpc feature now
  forwards tls-ring + tls-native-roots.
• Four new gRPC examples in crates/iota-sdk/examples/:
  chain_id_grpc, get_object_grpc, owned_objects_grpc,
  stream_checkpoints_grpc — the last has no GraphQL counterpart and
  exists specifically to showcase the streaming RPC.

Migration

This is a breaking change to the gRPC client surface. The mechanical
rewrite at call sites:

Before	After
get_objects(refs, None)	get_objects(refs)
get_objects(refs, Some(ReadMask::from(ObjectField::BCS)))	get_objects_masked(refs, ObjectField::BCS)
get_objects(refs, Some(ReadMask::from(&[ObjectField::BCS, ObjectField::REFERENCE])))	get_objects_masked(refs, [ObjectField::BCS, ObjectField::REFERENCE])
cp.summary()?.summary()?	cp.summary()?
cp.signature()?.signature()?	cp.signature()?
cp.contents()?.contents()?	cp.contents()?

XField::Y used to evaluate to &'static str; it's now an XField
struct. Use .as_str() if you need the underlying path string.

ReadMask<'_> is retained as a low-level string holder for advanced
composition but is no longer accepted by client methods directly — pass a
scoped mask (or a &str for the escape hatch) instead.

[Thoralf-M]

Overall not sure if this PR is really worth it, just providing None for the read mask if not needed or finding the correct things to mask doesn't seem to be a big deal to me

[DaughterOfMars]

Overall not sure if this PR is really worth it, just providing None for the read mask if not needed or finding the correct things to mask doesn't seem to be a big deal to me

I think it's a pretty big usability increase, if not for the extra helper fns than definitely for the read mask discoverability. Before you basically had no way to know what read masks to use other than reading the doc. Now it's implicit.

[muXxer]

Thank you very much for all the improvements on the grpc client.

I don't want to be picky, but I think the scope of this PR is way too big. There are so many changes that deserve their own PRs and discussions. I think we should rather create a feature branch and have scoped PRs for changes.

What I wouldn't do is to double the API surface with the new "masked" functions. Improvements in mask discoverability are welcome, but we should avoid doubling the API surface just because of an Option. Users should think about the mask they pass, to adapt it to the information they really need, because it reduces the network bandwidth and also the resource consumption on the server side.

[DaughterOfMars]

Thank you very much for all the improvements on the grpc client.

I don't want to be picky, but I think the scope of this PR is way too big. There are so many changes that deserve their own PRs and discussions. I think we should rather create a feature branch and have scoped PRs for changes.

What I wouldn't do is to double the API surface with the new "masked" functions. Improvements in mask discoverability are welcome, but we should avoid doubling the API surface just because of an Option. Users should think about the mask they pass, to adapt it to the information they really need, because it reduces the network bandwidth and also the resource consumption on the server side.

I could split this into two PRs, but regardless I do believe both changes should happen. It's no cost to have extra functions that make calling the API easier for users. Using the masks is a power-user feature, IMO, regardless of this PR.

[DaughterOfMars]

Replaced by #1253 and #1254