It uses the new format for the version because the new packages
are uploaded to this new vesrion

The duo workflow executor version has been bumped to v0.0.18, this
enables us to use the edit file tool.

This is related to
https://gitlab.com/gitlab-org/duo-workflow/duo-workflow-service/-/issues/80
. The changes in `v0.0.12` are needed to pass through the metadata that
was introduced in
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/167571 .

This corresponds to the tagged version we just created in
https://gitlab.com/gitlab-org/duo-workflow/duo-workflow-executor/-/pipelines/1472831822

I was originally planning on getting clients to download the exeucutable
file but it turns out this was tricky for our clients to use as the
[docker API](https://docs.docker.com/reference/api/engine/v1.43/#tag/Container/operation/PutContainerArchive)
we are using to copy the file into the container expects an archive to
expand. The `.tar.gz` file has the added benefit that it is about half
the size.

This is part of the
[Duo Workflow](https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/duo_workflow/)
feature. At present there is a binary called the `duo-workflow-executor`
that is downloaded on local VS Code installations as well as in CI
jobs to work as the execution engine for workflows. The binary is
developed in
https://gitlab.com/gitlab-org/duo-workflow/duo-workflow-executor . Right
now the URL to download the binary is
[hard-coded in the language server code for VS Code](https://gitlab.com/gitlab-org/editor-extensions/gitlab-lsp/-/blob/48d313386d056ab52668fbe65d4a34b9c07f13ea/src/common/constants.ts#L7).

Furthermore this change allows us to reduce duplicated binary URL
[hardcoding that we're going to have to do when we run the executor in CI](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/162091/diffs#e5c6c4ba6e74a571ad9ddffd9f04fd88813485b6_0_49).

Since the language server is already fetching other details (such as the
URL for Duo Workflow Service) from the `direct_access` API it also seems
reaonable to fetch this binary URL from there as well.

This change is motivated by
https://gitlab.com/gitlab-org/duo-workflow/duo-workflow-executor/-/issues/11
. The idea is that we will want to serve the `duo-workflow-executor`
binary from the GitLab instance itself in at least the following cases:

1. Local development where the executor is being developed and compiled
   locally
1. Self-managed air-gapped environments

With this change we can update the `executor_binary_url` to be a URL
served by GitLab. Then we can put that binary in a `public/assets`
directory in the GitLab instance so it can just be downloaded like a
normal asset. The GDK side of this work is being done in
https://gitlab.com/gitlab-org/gitlab-development-kit/-/merge_requests/3956
.

One downside of relying on this URL from GitLab is that it may take
longer to update that releasing an update to the VS Code plugin. But
even if we find ourselves needing to rush out an update we still have
the option later of ignoring this URL from the GitLab instance so it
seems like a low risk decision to make now.