[Feature]: Default working_dir to the image's working directory #3124

Current behavior

• The working directory is hardcoded to /workflow unless the user sets it explicitly.
• dstack uses /workflow to clone the repo if the user hasn’t specified a path.
• If the user specifies a relative repo path, it is placed inside the working directory.
• Files do not use the legacy repo directory. If no path is specified, or if it’s relative, they are mounted inside the working directory.

Planned changes

• By default, use the image’s default working directory.
• In our default Docker image, Change the working directory from /workflow to the user home directory (e.g. /root). This is to ensure the user experience for the default and non-default Docker images is similar).

WIth the regard to repos

There are several variants:

Variant 1: Default repo path to $DSTACK_REPO_DIR

• If the user hasn’t specified a repo path, clone the repo into DSTACK_REPO_DIR (for now, keep /workflow which can be changed later). Allow the user to cd into this directory in commands (for example, cd $DSTACK_REPO_DIR).
• If the user specifies a relative repo path, mount the repo inside the working directory.
• If the user specifies any repo path, also save it to DSTACK_REPO_DIR.

Variant 2: Default repo path to <working dir>/<repo name>

• If the user hasn’t specified a repo path, clone the repo into<working dir>/<repo name> (simulating how git clone <repo url> works).
• If the user specifies a relative repo path, mount the repo inside the working directory.
• If the user specifies any repo path, also save it to DSTACK_REPO_DIR.

Variant 3: Forbid no repo path

• Always require a relative or absolute repo path
• If the user specifies a relative repo path, mount the repo inside the working directory.
• If the user specifies any repo path, also save it to DSTACK_REPO_DIR.