Pre-publishing for Docker tools

### User Story

As a user, I want to publish the Sleeper Docker tools to my own system, so that I don't need to depend on GHCR.

### Description / Background

We'd like to support a pre-publishing flow for the Sleeper Docker Tools, similar to pre-publishing of the rest of Sleeper. Ideally we'd like to be able to include both in the same pre-publishing pipeline, but they don't need to be directly coupled.

Here's the documentation for the Docker Tools:

https://github.com/gchq/sleeper/blob/develop/docs/deployment/docker-tools.md

### Acceptance Criteria

**Scenario: Existing flow, download install script**
**Given** I download the Docker tools install script directly from GitHub
**When** I run the install script I downloaded, with no arguments and no local copy of the code
**Then** all components of the Docker tools are retrieved from GitHub against the develop branch

**Scenario: Alternative flow with pre-published version**
**When** I install the Docker tools with the script in a local Git repository
**And** I set an option to specify the container registry
**Then** container images are retrieved from the registry I set
**And** container images are retrieved with a tag of the version number in the local Git repository
**And** the script to run the CLI is installed from the local Git repository

**Scenario: Upgrade supports either flow**
**When** I run a command to upgrade the Docker tools CLI
**Then** both the script and the Docker images are retrieved from the same place that was originally used
**And** if installed from a local Git repository that has been updated, the Docker images are retrieved from a tag of the new version number

**Scenario: GHCR only has "latest" tag**
**When** I install the Docker tools with the default container registry
**Then** the "latest" tag is always used, because no other tag exists in GitHub Container Registry

### Technical Notes / Implementation Details

The pre-publishing pipeline can use the existing Docker build in `scripts/cli`.

The installation script is `scripts/cli/install.sh`, and part of that script's job is to put `scripts/cli/runInDocker.sh` on the system path, named "sleeper" so that running `sleeper` in a terminal will run that script.

To remember the new install options when upgrading the Docker tools (e.g. with `sleeper cli upgrade`), we'll need a configuration file that tracks whether we installed by downloading from GitHub or from a local Git repository, and whether we retrieve the container images from GHCR or a custom registry.

#### Configuration file

We can store a new configuration file in the user's home directory under `.sleeper` somewhere. We need to make the directory consistent with other places we store data there.

Currently the `~/.sleeper` directory is used when you run `sleeper builder` or `sleeper environment`, to store the builder workspace, and to track which environments have been deployed or connected to. Folders under this directory are mounted to these containers in `scripts/cli/runInDocker.sh` in `run_in_builder_docker` and `run_in_environment_docker`. The environment directory is written to in the scripts in `scripts/cli/environments/scripts/subcommands`.

We'll need to use a format for the configuration file that we can process effectively in Bash.

Start with scripts/cli/install.sh and scripts/cli/runInDocker.sh, then inspect the existing Docker build in scripts/cli and the ~/.sleeper usage described for builder and environment commands. Trace how installation and the CLI upgrade currently retrieve scripts and images. Done means both GitHub-download and local-repository installs support the stated registry and version behavior, preserve those choices for upgrades, and retain the existing GHCR latest-tag flow.

Written by the indexing model from the issue text.