Allow configuring where the Duo Workflow Executor binary is served from

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.