Ensure command args aren't parsed by rdbg

[Hawkbawk]

Ensure that all commands and arguments come after an options terminator, as heavily recommended by rdbg themselves. This ensures that rdbg doesn't attempt to parse and delete options that are meant for the program.

[Hawkbawk]

More Context

Previously, the bare command and all of its arguments were being passed directly to rdbg, without any argument separation. For example, given the following debug config:

[
  {
      "request": "launch",
      "adapter": "rdbg",
      "label": "Launch Rails Server with Ruby extension (Debug)",
      "command": "bin/rails server -p 8000",
      "cwd": "${ZED_WORKTREE_ROOT}"
  },
]

The command /path/to/rdbg --open --host=2130706433 --port=55075 --command bin/rails server -p 8000 will be used to start the debugger. The issue here is that rdbg ends up parsing the -p 8000 as an argument to itself, rather than to rails. This means that you can't specify a port for Rails and the debugger will actually fail to launch, as it doesn't end up listening on the port that Zed is expecting.

[vitallium]

thought (non-blocking): I wonder why we need to check if command_or_script exists in a worktree here. We should check that later.

[Hawkbawk]

From what I can tell, the requirement for command_or_script comes from the dap_config_to_scenario method. We aren't sure if what they're giving us is a script or a command, but we don't have access to the worktree in that method, so we forward it along and let the get_dap_binary deal with checking that. Agreed that we should investigate how necessary command_or_script is though.

[vitallium]

@Hawkbawk nice catch! I am happy to merge this but we have some merge conflicts here after #127. Would you mind resolving them? Thanks!

[Hawkbawk]

Conflicts fixed! Thanks for looking at these.

[vitallium]

Conflicts fixed! Thanks for looking at these.

Thanks!