Fix search for clang-win assembler

[sdarwin]

Fix clang-win init failure when vswhere does not find Visual Studio (e.g. Build Tools-only installs)

Problem

Since B2 5.5.0, initializing the clang-win toolset hard-fails on any machine
where vswhere does not report a Visual Studio installation:

tools/build/src/tools/clang-win.jam:148: in clang-win.init
error: rule path.make ( native )
error: called with: ( )
error: missing argument native

This is what has been failing the boostorg/beast develop-branch CI since late
June 2026 (last green run June 25, first failing run July 6, with no change to
the runners themselves):

https://github.com/boostorg/beast/actions/workflows/build.yml

The only failing jobs are the two that use toolset=clang-win:

windows (clang-win, 14,17,20,latest, 64, windows-2025)
windows (clang-win, 14,17,20,latest, 32, windows-2025, linkflags=/safeseh:no)

The timing is explained by the boost superproject's tools/build submodule
update on June 28 / July 1, 2026, which pulled in the 5.5.0 release and with
it commit 5865604 ("Fix search for clang-win assembler.", March 11, 2026).
That commit added a vswhere-based search for the MSVC assembler to
clang-win.init.

Root cause

Two issues in the vswhere block added by 5865604:

1. The vswhere invocation omits -products *. By default vswhere only
   reports Community/Professional/Enterprise products, so on machines that
   only have Visual Studio Build Tools installed (very common for CI
   runners, including the ones used by boostorg CI) it returns nothing.
   Note that B2's own msvc.jam and vswhere_usability_wrapper.cmd both
   already pass -products * for exactly this reason - which is also why
   the msvc toolset jobs on the same runners kept working.

2. The result is used unguarded. When vswhere prints nothing, vspath is
   an empty list, so the interpolated string

   [ path.make "$(vspath)\\VC\\Tools\\MSVC" ]
   

   expands to an empty list (standard Jam expansion semantics) and
   path.make is invoked with zero arguments, producing the
   "missing argument native" error above. This makes an optional
   convenience (locating the MSVC assembler) into a fatal error, even
   though the code already has fallbacks (assembler from the linker
   directory or PATH) for when the search finds nothing.

The mechanism is easy to reproduce on any platform:

import path ;
local empty ;
local p = [ path.make "$(empty)\\VC\\Tools\\MSVC" ] ;

jamroot.jam:3: in modules.load
error: rule path.make ( native )
error: called with: ( )
error: missing argument native

Fix

In clang-win.jam:

• Pass -products * to vswhere (quoted the same way msvc.jam does, for
  Cygwin builds), so Build Tools installations are found.
• Only run vswhere if it exists (same guard msvc.jam uses).
• Only glob the VC tools directory when vswhere actually returned an
  installation path. If nothing is found, msvcpath/vsasmpath stay empty
  and the existing fallback logic (assembler next to the linker, then
  PATH) takes over, as it did before 5.5.0.

Also adds a history.adoc entry.

Testing

• Verified the failure mechanism reproduces exactly (empty variable in the
  interpolated path.make argument) and that the guarded version survives
  both the empty and non-empty cases.
• Built the engine and confirmed clang-win.jam parses and clang-win.init
  runs through toolset.using (up to the expected clang-cl detection).
• The vswhere -products * behavior matches the existing usage in
  msvc.jam and vswhere_usability_wrapper.cmd, which correctly find Build
  Tools-only installations on the affected runners today (visible in the
  boostorg CI logs as "Found with vswhere C:\Program Files (x86)
  Microsoft Visual Studio\2022\BuildTools").

With this fix, clang-win init succeeds on:

• machines with full VS editions (unchanged behavior),
• machines with only VS Build Tools (previously: hard error),
• machines with no VS at all, e.g. LLVM-only setups (previously: hard
  error; now falls back to assembler from linker dir / PATH).