Fix lldb-server not copied to target device

[Athosvk]

When running the lldb command, lldb-server wouldn't be copied to the device, no matter if this was present on the xbuild host desktop or not. This would result in lldb saying it's not able to connect through the target port, but the warning that the copy failed because the executable wasn't present on the source desktop path was the real issue.

Some arguments were flipped quite some time ago, which caused it to always use the wrong path. Also, by default it would not allow for execution so added a chmod 777 to complete. Running this with on a clean device now correctly launches lldb from start to finish. Note that it is strange that the respective push commands don't indicate a failure, despite the source file (i.e. the lldb-server executable) not being present. After these changes x lldb is able to start successfully from a clean slate.

The lldb command still has issues for us as this results in it throwing this error:

thread #1, name = '{...}', stop reason = signal SIGSEGV: address access protected (fault address: 0x7fed809000)
    frame #0: 0x0000007fed809000 {...}.so
->  0x7fed809000: .long  0x464c457f                ; unknown opcode
    0x7fed809004: .long  0x00010102                ; unknown opcode
    0x7fed809008: udf    #0x0
    0x7fed80900c: udf    #0x0

This despite running with debuggable: true in our Manifest. Not sure if it's related directly to the lldb command's setup. Maybe someone else can chip in on what could be the issue for the above?

I still think the changes from this PR can go in though.

[dvc94ch]

thanks

[MarijnS95]

Why not reuse a+x from above?

[MarijnS95]

Note that it is strange that the respective push commands don't indicate a failure, despite the source file (i.e. the lldb-server executable) not being present

If I understand correctly, because of flipped arguments, wasn't it previously pushing the artefact that we tried to execute? Or is this a relative path/name?