feat: add dx print command, drive hotpatching engine directly.

[jkelleyrtp]

dx print

Adds a print command for printing the cargo args we pass off to the build system.

It supports a number of output formats to make it easy to integrate with 3rd-party build systems.

By default, it prints a runnable command which you can simply echo into your current shell and get a build running.

> dx2 print client-args
env cargo rustc --config 'profile.desktop-dev.inherits="dev"' --profile desktop-dev --target aarch64-apple-darwin --verbose --features desktop -p cpal-test --bin cpal-test -- '-Clink-arg=-Wl,-rpath,@executable_path/../Frameworks' '-Clink-arg=-Wl,-rpath,@executable_path'

It's designed so you can print either the client or the server with two different commands (client-args, server-args).

A number of output styles are available:

pub(crate) enum PrintStyle {
    /// Print the arguments as a list of arguments, one per line.
    /// Does not include the `cargo rustc` command itself
    Args,

    /// Print the environment variables as a list of key=value pairs, one per line.
    Env,

    /// Print the arguments using the Unix `env` command.
    Unix,

    /// Print the arguments using the Windows `set` command.
    Cmd,

    /// Print the arguments as JSON. Does not include the `cargo rustc` command itself
    Json,

    /// Print the arguments as pretty JSON. Does not include the `cargo rustc` command itself
    PrettyJson,
}

For json, you can use the jq tool to pull out fields in a structured format.

---

I had to make a few changes to request to support this.

• Passing BuildMode instead of Ctx
• Using OsStr in a few places
• Switching println! to eprintln! in a few places so we don't unnecessarily write errors to stdout which most people are parsing.

direct hotpaching engine drive

This PR also adds the ability to drive the hotpatching engine directly from the CLI without any watcher setup. This delegates the file watching, filtering, etc to the calling tool, but makes it much easier to use the subsecond engine directly. The point of this usecase is to wire up the docsite playground for hotpatching, though I imagine other CLIs might want to use it too.