Support f-strings

[cgwalters]

This crate would feel especially natural if we had "f-strings", see https://crates.io/crates/fstrings/

We could probably copy in that crate's code...the only thing we need to do is insert shell quotation. Perhaps we could extend the crate's macros to add something like f_mapped!(crate::internals::command_arg, $fmt, ...).

[cgwalters]

Though one problem is that {...} is quite common in shell - i.e. ${...}. So we would have ambiguity in e.g.

let foo = "bar";
bash!("echo ${foo}")

that'd be hard to resolve without actually parsing the whole script to figure out whether {} is preceeded by $.

One possibly related idea: change things so that rather than replacing all variables in the script via substitution, we render things as e.g.:

let foo = "bar";
bash!("echo ${foo}", foo);

set -euo pipefail
foo='bar'
echo ${foo}

IOW we require people to refer to injected variables via ${} so it feels more shell-like.

[cgwalters]

Maybe it's more ergonomic to move the bindings first too?

        bash!(url, 
            "ostree remote delete --if-exists testrepo
             ostree remote add --set=gpg-verify=false testrepo ${url}",
        )?;

[cgwalters]

Or we only fstring-substitute variables prefixed with ${rust.url} so this would be:

        bash!("ostree remote delete --if-exists testrepo
             ostree remote add --set=gpg-verify=false testrepo ${rust.url}",
        )?;

[cgwalters]

OK so https://blog.rust-lang.org/2022/01/13/Rust-1.58.0.html#captured-identifiers-in-format-strings landed.

I'm thinking the above mentioned code like:

let url = "https://example.com";
bash!("curl -LO ${rust.url}")?;

would be most elegant. But as far as I can tell, all the machinery to handle format! and parsing the string is inside the compiler. We need two things here - to capture the named arguments, and to transform them by shell-quoting them.

The status quo today is that the underlying format_args is compiler internal.

But, I would guess we could still do the same with a proc macro. The ugly part really of this is that we need to parse the input, but I guess we already depend on shlex so doing that at compile time is certainly doable.