build: give spec.build.defines a reader that cannot lie - #7159

Eight core gems announce a capability to the rest of the build by adding to
`spec.build.defines`: `MRB_USE_BIGINT`, `MRB_UTF8_STRING`,
`HAVE_MRUBY_IO_GEM`, `MRB_USE_TASK_SCHEDULER` and the like. No gem reads one
back. The three `defines.include?` calls in `mrbgems/*/mrbgem.rake` all read
the gem's own `cc.defines` or one the build configuration set, never one
another gem contributed.

The channel is write-only for a reason. A gem contributes its defines when
its own mrbgem.rake body runs, and `MRuby::Gem::List#setup` runs those bodies
in the order the gems were added, so a gem that reads `build.defines` during
that phase gets an answer that depends on where it sits in the list.
`full-core.gembox` globs the directory, and `mruby-encoding` sorts before
`mruby-regexp`, so the one pairing that would be asked about today happens to
work. Naming the two gems in the other order is enough to break it:

```ruby
MRuby::Build.new('probe') do |conf|
  conf.gem :core => 'mruby-regexp'
  conf.gem :core => 'mruby-encoding'   # contributes MRB_UTF8_STRING
  conf.gembox 'default'
end
```

Read from `mruby-regexp`'s block, `build.defines.include?('MRB_UTF8_STRING')`
is `false` there and `true` with the two lines swapped. Both builds compile
with `-DMRB_UTF8_STRING`.

`MRuby::Build#has_define?` answers the same question and refuses to answer it
early:

```
build.has_define?("MRB_UTF8_STRING") cannot be answered while gems are still
being set up, because a gem contributes its defines then. Ask from a
`spec.build_settings` block instead.
```

`build_settings` is called from `MRuby::Gem::List#check`, after every gem's
setup, which is where the answer is stable. The Rakefile marks the boundary
once per target, right after `gems.setup`, so a build with no gems reaches it
too.

The reader spans both places a define can come from, `build.defines` and the
compilers' own, and matches on the name alone, so a define added as `FOO=1`
answers `has_define?("FOO")`. The `-D` belongs to the compiler flag and not to
the define, so it is no part of the name to ask under.

### Verified

On the config above and on `ci/gcc-clang`, printed from both phases:

```
probe-bad-order   setup: REFUSED       build_settings: true
full-debug        setup: REFUSED       build_settings: true
bintest           setup: REFUSED       build_settings: true
cxx_abi           setup: REFUSED       build_settings: true
byte-string       setup: REFUSED       build_settings: false
```

`byte-string` is `full-core` minus `mruby-encoding`, so `false` is the whole
of the difference. A define carrying a value (`PROBE_VALUED=7`) answers under
its name, and a name nothing defines answers `false`.

`MRUBY_CONFIG=ci/gcc-clang rake -m test`, all four builds and the bintests,
KO 0:

```
byte-string   Total 2227   Skip 29
full-debug    Total 2288   Skip 2
bintest       Total 2289   Skip 10   + 116 bintests
cxx_abi       Total 2289   Skip 10
```

### No caller yet

Nothing in the tree calls it. The gems that split their tests by build mode
(`mruby-string-ext`, `mruby-regexp`) do it at run time with `skip unless`,
which needs no build-time answer and stays the better tool for that job. This
is for a gem that has to configure itself, not its tests, against another
gem's capability, and it is offered so that the first one to need it finds a
question it cannot get wrong rather than an array it can read too early.