Each item in the `files` property maps a local path (a file or a dir)
to a container path. Each local path is packed into a tar archive and
uploaded to the server similar to the code repo archive/diff.

On the server, each archive is stored in the DB as `FileArchiveModel`
linked to the user. Archive blobs are optionally uploaded to
the storage (again, similar to the code blob).

When the job is submitted to the runner, files (if any) are uploaded
after `/api/submit` but before `/api/upload_code`.

The runner unpacks archives as follows:
* If the path already exists, it's removed
* If any parent dirs of the path are missing, they are created as owned
  by the run user. The owner of the existing dirs is not changed.
* The owner of the path (and all subpaths in the case of the directory)
  is set to the run user. The permissions from the archive (and thus
  from the user's machine) are preserved.

Part-of: #2738

* Implement secrets management API

* Test secrets management API

* test: add test cases for delete secrets endpoint

* Check secrets exist before deleting

* Add dstack secret CLI command

* Interpolate env with secrets

* Interpolate registry_auth with secrets

* Validate secrets

* Rebase migration

* Document secrets

Add the local backend to `BACKENDS_WITH_*_SUPPORT`
so that it can be used in fleet configurations.

- Support rolling deployments for services when
  the run repo is updated: new commits are added,
  the branch is changed, uncommitted files are
  updated, etc. Switching from one repo to another
  is not yet supported.

  > **Note**: A side effect of this change is that
  if the run configuration file is stored in the
  same repo that is used for the run, any changes
  to the configuration file will also be
  considered a change to the repo
  (`repo_code_hash`), and hence require a rolling
  deployment for services or a full restart for
  tasks and dev environments. Previously, this was
  not the case, since changes to `repo_code_hash`
  were ignored for existing jobs. This new
  behavior makes it more difficult to avoid
  redeployment when changing some configuration
  properties, namely `priority`,
  `inactivity_duration`, `replicas`, and
  `scaling`. However, we consider this acceptable,
  since changing these properties in-place is an
  advanced use case and can still be achieved by
  moving the configuration file out of the repo.

- Improve run plan output in `dstack apply` when
  attempting an in-place update:

  - Show not only the list of changed
    configuration properties, but also other
    changes from the run spec, such as
    repo-related changes.

    ```shell
    $ dstack apply -f test-service.dstack.yml

    Active run test-service already exists. Detected changes that can be updated in-place:
    - Repo state (branch, commit, or other)
    - Repo files
    - Configuration properties:
      - env

    Update the run? [y/n]:
    ```

  - Show the list of changes not only when
    in-place update is possible, but also when it
    is not. This will help users understand why a
    run cannot be updated in-place.

    ```shell
    $ dstack apply -f test-service.dstack.yml

    Active run test-service already exists. Detected changes that cannot be updated in-place:
    - Repo files
    - Configuration properties:
      - gateway

    Stop and override the run? [y/n]:
    ```

    Currently, all detected changes are listed
    together. An area for future improvement is
    highlighting the changes that prevent an
    in-place update.

Move `LOCAL_BACKEND_ENABLED` from
`dstack._internal.server.settings` to
`dstack._internal.settings`, so that it can be
imported to both `dstack._internal.server` and
`dstack._internal.core`.

Support rolling deployments for services when the
`files` property is updated or the contents of
file archives change.

Currently, `dstack` always detects phantom changes
to file archive contents, since file archives are
omitted when getting the run plan. Addressing this
is out of scope for this PR.

This PR does not address compatibility with
previously submitted jobs that are using files,
because the files feature has not been released
yet, so no users have such jobs.

Fix this error when requesting a service running
on the local backend and served by the in-server
proxy:

```python
  File "/dstack/src/dstack/_internal/proxy/lib/services/service_connection.py", line 82, in open
    await self._tunnel.aopen()
  File "/dstack/src/dstack/_internal/core/services/ssh/tunnel.py", line 204, in aopen
    raise get_ssh_error(stderr)
dstack._internal.core.errors.SSHError: Connection closed by UNKNOWN port 65535
```

If the replica runs on the local backend, connect
directly to the container, without proxy jumping
through the shim host. Similar to workarounds in
`SSHAttach` and `runner_ssh_tunnel`.

* [Docs] Added `Files` to `concepts/dev-environments`, `concepts/tasks.md`, and `concepts/services.md`

* [Docs] Mentioned `.gitignore` and `dstackignore` in `Files` section

Use the runner process user (`root` expected) as the job user if
the `user` directive is not specified in either the image
or the dstack configuration.

Previously, the repo dir (`/workflow`) was used as a fallback for
the home dir if the user is not specified.

Fixes: #2864

After some testing, allow in-place update for more
properties that already work out of the box:
- `configuration_path` for all run types
- `working_dir` and `docker` for services,
  triggers rolling deployment