[feature] Accept user input for additional launch arguments when switching jobs

Hey all, thanks for the awesome tool!

I'm currently working in monorepo-style repository that has a, uhh... non-trivial number of packages under a root workspace. One of the downsides to this repository model is that running build-all or test-all style commands tends to be a _little_ slow (I'm looking at you, rust-analyzer). My workflow generally revolves around moving between `cargo check --package A`, `cargo test --package B`, `cargo watch --package C`, etc., and keeping a `bacon check -- --package SomeProcMacroNonsense` off to the side has really helped speed up some of my iteration times.

Unfortunately, I'm pretty much unable to use the job switching keybinds because I consistently need to re-target packages. Exiting the bacon process and relaunching with different cli arguments is obviously a functional answer, but it makes me feel like I'm... missing out(?) for lack of a better phrase.

I feel that adding some kind of (optional!) user-input injection when switching to or starting up a job would fill a gap. The default `bacon ex` command actually makes for a pretty good example;
```toml
# This parameterized job runs the example of your choice, as soon as the code compiles.
# Call it as
# bacon ex -- my-example
[jobs.ex]
command = ["cargo", "run", "--example"]
need_stdout = true
allow_warnings = true
```

Imagine dropping some kind of placeholder into that command, `command = ["cargo", "run", "--example", "{Example name}"]`. It would require more complex argument parsing and some TUI magic, but if a user started a `bacon check` job (without additional launch args), made changes to one of their examples, then used the jobs menu to launch the `ex` job, bacon could open an `Example name: ____` dialog/prompt that would let the user input the name of the example they want to launch.

As far as I can tell, this wouldn't need to change the semantics of additional launch arguments as they stand today -- those could still be passed into every job switched to during an execution of bacon. The exact semantics and syntax of this kind of dialog injection probably needs some thought, though, as my proposal is very much proof-of-concept level and doesn't consider the actual implementation in the TUI, the current command parsing logic, what happens if there are multiple placeholders, default argument, etc., etc..