projectGenerator (vs): addon .c sources compiled as C++, causing unresolved externals (ofxLua: 55)

Summary

openFrameworksCommon.props sets <CompileAs>CompileAsCpp</CompileAs> for all ClCompile
items, and projectGenerator emits no per-file override for addon .c sources. Any addon
shipping C code therefore compiles cleanly and then fails to link.

Reproduction

OF 0.12.1 (also 0.11.0, 0.11.2, 0.12.0), Windows 11, projectGenerator -p vs with ofxLua,
which vendors Lua as 34 .c files under libs/lua/.

projectGenerator.exe -oC:\of0121 -pvs -a"ofxLua" C:\of0121\apps\myApps\test

The generated project contains 35 .c files, none with a CompileAs override:

.c files in vcxproj : 35
with <CompileAs>CompileAsC : 0

They are compiled as C++ (per the props default), which C++-mangles their symbols. Meanwhile
ofxLua.cpp includes the Lua headers under extern "C" and references undecorated names, so:

34 source files compile with ZERO errors, then:
ofxLua.obj : error LNK2001: unresolved external symbol luaL_newstate
ofxLua.obj : error LNK2001: unresolved external symbol lua_close
ofBindings.obj : error LNK2001: unresolved external symbol luaL_loadstring
...
LNK1120: 55 unresolved externals

The "compiles clean, then 55 link errors" shape makes this quite hard to diagnose — nothing
points at the language mode.

Where it comes from

libs/openFrameworksCompiled/project/vs/openFrameworksCommon.props:

<ClCompile>
  <CompileAs>CompileAsCpp</CompileAs>
</ClCompile>

Both the app project and openframeworksLib.vcxproj chain to that file, so the default applies
to addon sources too.

Workaround

A per-file override, which MSBuild honours over the ItemDefinitionGroup default:

<ClCompile Include="..\..\..\addons\ofxLua\libs\lua\lapi.c">
  <CompileAs>CompileAsC</CompileAs>
</ClCompile>

Because PG rewrites the .vcxproj on every run, this has to be reapplied after each
regeneration — easy to forget, and it fails as 55 unrelated-looking link errors.

Note

The 0.11.1 changelog describes commit 9eabc1c (splitting PLATFORM_CFLAGS /
PLATFORM_CXXFLAGS) as addressing .c-compiled-as-C++. That fixes the Makefile path; the
VS path still emits zero CompileAsC, verified by regenerating on 0.11.2, 0.12.0 and 0.12.1.