service update: private dicts are lost unless client has secrets

## Problem

When doing `edgly service update` (and creating a new version), and the Fastly service has private dictionaries with secrets in it, but the deployer does NOT have those secrets locally (and not set as env vars), then those secret values will be effectively removed in the new version.

There is no way to read values from private dictionaries. Only inside the actual VCL at runtime (we can't access that with edgly), and indirectly only with the service version cloning API - which is what the UI uses when you click "edit configuration".

Also the current approach creates new dictionaries on each new version, which is visible in the vcl diff between versions as all the dictionary ids change.

## Solution

Two options:
1. put the burden on the deployer: the user must always have the credentials when calling `edgly service update`.
- problem: maybe the secrets should not be exposed on a developer's laptop. could be resolved if this all happens in a CI/PR workflow.
- problem: if there is a separate key rotation CI process, that updates keys in the live dictionary directly, then it would be a bit more complex if this _also_ has to happen in the deploy (CI) step
2. change `edgly service update` to be based on the clone API
- problem: "removing" things aka achieving the overwrite from Fastly would be more work in all the places outside the edge dictionary case. I.e. a list of snippets on Fastly would have to be deleted first after the clone, before we write the local snippets, to ensure only the local ones are present on the Fastly side afterwards.
- problem: that would take away from the idea that edgly would entirely overwrite/push the local state to Fastly. it is now possible that any changes done on the Fastly service side will stay. however this would only apply to settings that edgly does not support (and go through separate API calls)

Start with the edgly service update flow and the Fastly service-version and private-dictionary handling described in the issue. Compare the current update behavior with the service version cloning API, then define whether secret values and dictionary IDs are preserved while local state is still applied consistently.

Written by the indexing model from the issue text.