Describe the bug
With the recent change (commit 5bdb9d6) that incorporates a pre-built binary that is downloaded during the bootstrap process, the overall user experience is clunky/inconsistent when using vcpkg on Alpine linux

Environment

• OS: Alpine linux
• Arch: x86_64

To Reproduce
Steps to reproduce the behavior:

1. clone vcpkg
2. run bootstrap.sh, user sees...

Downloading vcpkg-muslc...

3. attempt to install any package. for example, zlib.

/src/vcpkg # ./vcpkg install zlib

Computing installation plan...
The following packages will be built and installed:
    zlib[core]:x64-linux -> 1.2.11#13
Detecting compiler hash for triplet x64-linux...
A suitable version of ninja was not found (required v1.10.2). Downloading portable ninja v1.10.2...
Downloading ninja...
  https://github.com/ninja-build/ninja/releases/download/v1.10.2/ninja-linux.zip -> /vcpkg/downloads/ninja-linux-1.10.2.zip
Extracting ninja...
sh: /vcpkg/downloads/tools/ninja-1.10.2-linux/ninja: not found

Failed to get version of /vcpkg/downloads/tools/ninja-1.10.2-linux/ninja

The problem is that the downloaded support tool cannot work in Alpine linux.

Expected behavior
The combo of now providing a pre-built vcpkg binary built for the musl-based system but downloading a tool binary that doesn't work is very confusing. From a broad point of view, it would be nice to see one of the following behaviors:

1. all tools (vcpkg, ninja, etc) built to the same standard. thus avoiding any additional workaround. If a vcpkg is provided then the other tools should be usable, or
2. when vcpkg is downloaded, a warning message stating that the VCPKG_FORCE_SYSTEM_BINARIES is required, or
3. vcpkg attempts to find the system binaries automatically when on a musl-based system, or
4. in the worst case, just remove the musl-based pre-built binary and just let the user build from source. in this manner, you'd at least have a very consistent experience.