[RSDK-13658] Plumb force_relay/force_p2p/turn_uri through C FFI

[danielbotros]

Summary

• Plumbs the DialBuilder options landed in [RSDK-13658] Add force relay and force p2p dial flags #170 (force_relay, force_p2p, turn_uri) through the C FFI as an opaque, ABI-stable options handle; new fields in the future require only a new setter, never a header change.
• viam_dial (7-arg) is left untouched. Non-Rust consumers (C++ SDK) see no breaking change. It is now #[deprecated] in favor of viam_dial_with_opts.
• Consolidates viam_dial, the deprecated dial, and the new viam_dial_with_opts onto a shared private dial_impl so they can't drift.
• Consumed by [RSDK-13658] Expose force_relay/force_p2p/turn_uri DialOptions viam-python-sdk#1208.
• New FFI surface:

  void *viam_dial_opts_new(void);
  void  viam_dial_opts_free(void *opts);
  void  viam_dial_opts_set_force_relay(void *opts, bool value);
  void  viam_dial_opts_set_force_p2p(void *opts, bool value);
  void  viam_dial_opts_set_turn_uri(void *opts, const char *value);
  char *viam_dial_with_opts(..., const void *opts);  // NULL opts = defaults

• The internal DialOpts struct never appears in the generated header; cbindgen sees only void *. Future field additions don't break the C ABI.

Test plan

• cargo build --release + cargo clippy --all-features clean
• cargo test --release --lib passes (4/4)
• nm confirms exports: _viam_dial_opts_new/_free/_set_*, _viam_dial_with_opts, _viam_dial (deprecated), _dial (deprecated)
• cbindgen regenerates a clean header. Every opts param is void *, the DialOpts Rust struct never appears
• C test harness compiles+links: exercises 7-arg viam_dial, opts lifecycle, all setters (NULL/empty/value paths), and viam_dial_with_opts. -Wall -Wextra clean, links against the dylib
• (manual) coturn dial verifying force_relay pins to relay candidates and force_p2p strips them — pending with the paired python-sdk PR

[stuqdog]

The logic changes all look reasonable but I'm pretty sure this will break existing C++ SDK instances. When C++ builds it looks for an existing rust-utils instance and if it doesn't find one it just downloads the latest release.

One possible fix would be to update the cbindgen process to generate a function overload signature for viam_dial that uses the old signature and puts default values in. Happy to chat more in person if you have questions or thoughts!

[danielbotros]

The logic changes all look reasonable but I'm pretty sure this will break existing C++ SDK instances. When C++ builds it looks for an existing rust-utils instance and if it doesn't find one it just downloads the latest release.

One possible fix would be to update the cbindgen process to generate a function overload signature for viam_dial that uses the old signature and puts default values in. Happy to chat more in person if you have questions or thoughts!

I went ahead and changed the cbindgen config to emit a C++ only header that fills in default values for the last 3 new dial options args so the C++ SDK can compile against the 10-arg header.

This requires a small follow up PR to the C++ SDK to update the viam_dial stub to 10-args for machines on a non-x86_64 Windows platform to compile against since they don't pull a rust-utils binary and can't dial but can still interface modules. Pretty sure this a breaking change for them, if anyone is even running that kind of setup...

[stuqdog]

nice, this looks good to me!