mruby-bin-mrbc: take the target define from the compiler gem - #7172

`MRC_TARGET_*` decides the layout of `struct mrc_ccontext`, so this tool's
translation units and `mruby-compiler`'s have to carry the same one. Each
derived it on its own from the same three questions, and each read its own
copy of the compiler's define list, taken at a different moment:
`mruby-compiler` reads its copy while the gems are being set up, this gem's
is reset to the build's when `build_settings` runs, once every gem is set up.
A `PICORB_VM_*` contributed in between is in one answer and not the other,
and the disagreement reaches the link as field offsets that differ, not as
a build error:

```ruby
MRuby::Build.new('probe') do |conf|
  conf.toolchain
  conf.gembox 'full-core'
  conf.gem "#{MRUBY_ROOT}/examples/mrbgems/c_extension_example" do |g|
    g.build.cc.defines << 'PICORB_VM_MRUBYC'
  end
end
```

`mruby-compiler` answers `MRC_TARGET_MRUBY` there and the tool answers
`MRC_TARGET_MRUBYC`, both compiled with `-DPICORB_VM_MRUBYC`.

Copy what that gem settled on instead. It is set up by the time this block
runs, whatever order the gems were processed in, so the copy holds whatever
it decided, and a build that defines `MRB_NO_GEMS` with no `PICORB_VM_*`
still gets no target define on either side. `spec.cc.defines.flatten!` goes
with the `include?` calls it was there for; the compile line flattens the
list again when it assembles the flags.

### Verified

Both gems answer `MRC_TARGET_MRUBY` on the probe above, and the `mrbc`
sub-build, which defines `MRB_NO_GEMS`, gets no target define on either
side, as before.

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

    bintest       117 bintests
    bintest       2303   Skip 10
    byte-string   2239   Skip 29
    cxx_abi       2303   Skip 10
    full-debug    2302   Skip 2

`MRUBY_CONFIG=default rake -m test`, Total 2085 KO 0, plus 106 bintests.