Fix `--args` and handle merging in `@server` and `@client`

[ealmloff]

You can pass args to the executable(s) opened by dx after a trailing -- just like cargo run:

dx serve --args "arg1 arg2"
dx run --args "arg1 arg2"

Fixes #4122 Fixes #4250

[rami3l]

@ealmloff Many thanks for the patch! I've tried it locally on my project and it works pretty well without issues. Is there any remaining blocker preventing this from being merged?

[jkelleyrtp]

We added support for multi-platform serve:

dx serve \
  @client --package dashboard \
  @server --package server

How does this PR interact the multi-target builds? It seems like we can only pass args to the final target?

[ealmloff]

We added support for multi-platform serve:

dx serve \
  @client --package dashboard \
  @server --package server

How does this PR interact the multi-target builds? It seems like we can only pass args to the final target?

Currently, it passes args to both binaries if you serve desktop + fullstack. It looks like subcommand_precedence_over_arg in the subcommand doesn't see through the -- args. This command doesn't work dx serve -- args @client ... @server .... I would like to support something like this:

dx serve -- shared args @client -- client args @server -- server args 

It might require parsing more stuff manually without clap. We also currently only allow separate build args for the client and server, not serve args like --open and we don't handle merging shared args with the separate args

[ealmloff]

I couldn't find a good way to get the last argument working with subcommand, so I switched back to a string args. You can now do dx serve @client --args "foo" @server --args "bar"

@client and @server also handle merging args and work with serve args where it makes sense to do so

[rami3l]

@ealmloff Many thanks again! I have updated my local build to match b70e60b and can confirm the new syntax is indeed working in my case.

Is there anything I could do to help this PR get merged? Thanks in advance!