feat: support locally provided CLI binaries via binaryDestination

[fioan89]

The existing CLI resolution logic hardcodes the CLI name based on the OS and architecture without any flexibility in specifying an existing CLI. It has a couple of options to specify the download dir (binDir and dataDir) but not the CLI name. This PR revolves around the bindDir setting which is now renamed to binaryDestination and it allows users to specify an absolute path to an existing executable filename or a destination dir. If the user specifies the destination dir then the CLI name will use the existing default name based on the os and architecture.

In addition a couple of windows tests were refactored because they required git bash utilities to be installed on Windows. Recent builds on the Github CI failed because commands like printf were not available.
A lot of UTs were also added to cover the behavior of CLI resolution when based on how binaryDestination, dataDir, enableDownloads and enableFallback flags are configured. Now there is also a special section in the README detailing the CLI resolution algorithm.

By and large we tried to keep the existing behavior without breaking compatibility for existing users who were supposed to configure a folder in the binaryDir.

The new behavior works like this:

1. Look at the binaryDestination, and if it points to an existing executable file check it if it's version matches server version:
    1.1 If it matches then return it.
    1.2 If it doesn't match then check whether downloads are enabled
        1.2.1 if it is enabled then download the server version of CLI and overwrite the one at binaryDestination
        1.2.2 if it is not enabled then check `$dataDir/$hostname/coder-$os-$arch.$ext
               1.2.2.1 if the CLI in the dataDir exists and matches, then return it.
                1.2.2.1 otherwise prefer the CLI from binaryDestination over the one from dataDir
2. If binaryDestination points to a directory, check $binDestination/$hostname/coder-$os-$arch.$ext if it's version matches server version:
    2.1 If it matches then return it.
    2.2 If it doesn't match then check whether downloads are enabled
        2.2.1 if it is enabled then download the server version of CLI and overwrite the one at $binDestination/$hostname/coder-$os-$arch.$ext 
        2.2.2 if it is not enabled then check `$dataDir/$hostname/coder-$os-$arch.$ext
               2.2.2.1 if the CLI in the dataDir exists and matches, then return it.
                2.2.2.1 otherwise prefer the CLI from $binDestination/$hostname/coder-$os-$arch.$ext  over the one from dataDir

• resolves If coder is installed via winget, local binary fallback fails because plugin expects release artifact name instead of installed executable name #285