feat: expose open_session API and add TcpConnect local command

[jdjingdian]

Motivation

Currently there is no way for library consumers to open arbitrary ADB services (e.g. tcp:<port>) directly over a USB or TCP transport. This is the minimal foundation needed to implement adb forward semantics without requiring an intermediate adb server process.

Use case: a Rust application that connects to a device over USB and needs to establish a TCP tunnel to a port on the device (e.g. for debugging daemons, custom protocols, etc.).

Changes

• ADBMessageDevice::open_session: visibility changed from pub(crate) to pub, with doc comment
• ADBSession accessors: new, get_transport_mut, local_id, remote_id — added doc comments (already pub, now documented)
• ADBUSBDevice::inner_mut(): new method exposing the inner ADBMessageDevice for advanced operations
• ADBLocalCommand::TcpConnect(u16): new enum variant that formats to "tcp:<port>" — the standard ADB local service for device-side TCP connections
• Re-exports: ADBLocalCommand and ADBMessageDevice are now accessible from the crate root

Usage Example

use adb_client::{ADBUSBDevice, ADBLocalCommand};

let mut device = ADBUSBDevice::new(vendor_id, product_id, private_key_path)?;
// Open a TCP connection to port 8080 on the device
let session = device.inner_mut().open_session(&ADBLocalCommand::TcpConnect(8080))?;
// `session` now represents a bidirectional byte stream to device:8080
// Use session.get_transport_mut() for read/write operations

Notes

• This is a non-breaking, additive change — no existing API signatures are modified
• The TcpConnect variant maps directly to the ADB protocol's tcp:<port> service, which is handled natively by adbd
• This lays groundwork for higher-level forward abstractions in future PRs

[cocool97]

Thanks for your PR !

I'm not a big fan of exposing ADBSession that was thought to be an internal type, same as exposing the 'raw' transport.

The goal / example of your PR looks very close to the forward command implementation, only missing a local port binding if I'm right. Do you have another use case in mind that would require exposing both session and transport to users ? If not I would prefer directly implementing the forward method to keep all this internal logic hidden to users.