build: hold the build's own defines in a separate list - #7175

Command::Compiler#defines holds two kinds of define at once. Most of what
lands there is what the build configuration and the gems asked for. Four sites
write the other kind, where the build adds a define on its own behalf because
one of its switches was flipped:

This PR moves those four into internal_defines, a second list on the same
object. Command::Compiler#all_flags reads both, so every build compiles with
the same -D set as before, and a build configuration keeps writing
conf.cc.defines the way it does today.

The toolchain overwrote the configuration

The visualcpp site is not an append but an assignment:

compiler.defines = %w(MRB_STACK_EXTEND_DOUBLING)

so a configuration that named its own defines before selecting the toolchain
lost them:

MRuby::Build.new('msvc') do |conf|
  conf.cc.defines << 'MRB_NO_STDIO'
  toolchain :visualcpp
end

MRB_NO_STDIO was gone from the build, silently. Nothing in the tree is bitten
today: build_config/ci/msvc.rb and the other MSVC configurations call
conf.toolchain :visualcpp before they name a define, which is the one order
that survives. The toolchain now writes a list no configuration writes, so the
order stops mattering.

has_define?

Command::Compiler#has_define? answers from both lists, comparing the name and
not the value so a define carrying one (FOO=1) still matches. mruby-compiler
is the one gem that has to read a build switch, and it reads it here:

# mrbgems/mruby-compiler/mrbgem.rake
cc.defines << 'MRC_DEBUG' if cc.has_define?('MRB_DEBUG')

It cannot ask build.has_define?: that refuses to answer until
defines_final!, because a gem contributes its defines when its own
mrbgem.rake body runs, and this line runs during that pass. Asking the compiler
is the answer that does not depend on gem order, since the build wrote
MRB_DEBUG before any gem was set up. Without the change the test would read
false under conf.enable_debug, MRC_DEBUG would go missing, and
PRISM_BUILD_MINIMAL would stub out pm_prettyprint(), taking the AST dump of
mruby -v with it.

Build#has_define? covers internal_defines too, so a build switch stays
visible to a gem that asks about it from spec.build_settings.

Testing

rake -m test, all green:

The debug build's -D set is unchanged and MRC_DEBUG survives the move:

$ build/host-debug/bin/mruby -v -e 'p 1'
mruby 4.0.0 (2026-04-20)
@ ProgramNode (location: (1,0)-(1,3))
+-- locals: []
+-- statements:
...

The C++ ABI build compiles with MRB_USE_CXX_EXCEPTION MRB_USE_CXX_ABI as
before, and mruby-compiler still adds __STDC_LIMIT_MACROS and
__STDC_CONSTANT_MACROS from build.cxx_abi_enabled?.

No test accompanies the change. The Rake build has no test harness of its own,
and the three builds above are what exercises the four moved sites.

Summary by CodeRabbit

• Bug Fixes
  • Improved compiler configuration handling so debug and C++ build options are applied more consistently.
  • Ensured internally selected build settings are recognized when checking compiler capabilities.
  • Improved Visual C++ builds by correctly applying stack extension behavior.
  • Updated compiler configuration documentation to better reflect supported build settings.