New tool releases shouldn't break fcli tool * install commands

[rsenden]

If no version is specified on the fcli tool * install command, fcli will install latest. This will fail with a digest mismatch though if latest has been updated, but fcli hasn't been updated with the new digest for latest. This means that whenever a new version is released of any of the tools supported by the fcli tool * install commands, pipelines may suddenly start failing, and users either need to modify their pipeline to explicitly specify a tool version, or wait for a new fcli version with updated digest(s) to be released.

Instead of installing latest, fcli by default should probably install the 'latest version known by fcli':

• For example, if the latest sc-client listed in sc-client.yml is 22.2.0, fcli will by default install this version instead of latest, effectively ignoring any new sc-client versions until a new fcli version with updated sc-client.yml is released
• The tool-specific YAML files already support a defaultVersion attribute, so to implement this approach, we simply need to update this attribute to point to an explicit version number instead of latest

Even with the above change, users could potentially still install the latest version by explicitly running fcli tool * install latest; we probably want this command to succeed even if fcli doesn't (yet) know the digest of that latest version. Some possibilities to accomplish this (some of these could potentially be combined):

• Make the digest attribute in the tool-specific YAML file optional, and don't define a digest on latest, thereby instructing fcli to not perform any digest check when installing latest. Fcli should probably log a warning stating that integrity cannot be guaranteed.
• Add a CLI option like --on-digest-mismatch=fail|warn|ignore that allows specifying what to do on a digest mismatch; either fail (default), log a warning (possibly default when installing latest), or just ignore completely.
• Add a CLI option to override the digest specified in the tool-specific YAML file, like --override-digest:sha256:...

Potentially we can also allow users to fully override the tool-specific configuration files, allowing users to specify alternative download locations with alternative digests; also see #158.