0.7.1 --- no loop becomes a C runtime call, at any optimization

[Sunrisepeak]

Every program built with --release for x86_64-windows-gnu above this package
received a shortened argument vector, by a different number of bytes per argument
and per run, and the dev profile never showed it:

dev:     argv[2]=[--timeout] strlen=9    kal_env_arg(1) -> 3
release: argv[2]=[--timeou]  strlen=8    kal_env_arg(1) -> 10

The optimizer recognised wide_length in src/env.cpp — a loop counting
sixteen-bit units to a terminator — and replaced it with a call to wcslen.
This package uses no C runtime symbol by design, so the call resolved to the C
library above it: openkal-musl, whose wchar_t is thirty-two bits. Its wcslen
read the command line two units at a time, so prepare() recorded wrong lengths
for every argument and every environment entry. Disassembly of prepare() in a
release consumer shows callq wcslen twice; with this change it shows none.

The same holds for bytes: a release build of this package's own objects
references strlen (from src/win.cpp), which the "no C runtime symbol" check
did not see because it builds the dev profile only.

• -fno-builtin beside -fno-exceptions -fno-rtti: the loops stay loops.
  memset is still emitted, and was already in the permitted set.
• The "objects reference no C runtime symbol" step builds and checks both the dev
  and the release profile.
• 0.7.1.

Found through lsp-mcpp, whose release-built tools rejected --timeout as
--timeou on windows-2022. Measured under Wine: a release build of a program
that prints its arguments and kal_env_arg lengths is wrong before this change
and matches the dev build after it.