Can we unpoison CONFIG_FOO macros?

[Markus Armbruster <armbru@redhat.com>]

We have a boatload of CONFIG_FOO macros that may only be used in
target-dependent code.  We use generated config-poison.h to enforce.

This is a bit annoying in the QAPI schema.  Let me demonstrate with an
example: QMP commands query-rocker, query-rocker-ports, and so forth.
These commands are useful only with "rocker" devices.  They are
compile-time optional.  hw/net/Kconfig:

    config ROCKER
        bool
        default y if PCI_DEVICES
        depends on PCI && MSI_NONBROKEN

The rocker device and QMP code is actually target-independent:
hw/net/meson.build puts it into softmmu_ss.

Disabling the "rocker" device type ideally disables the rocker QMP
commands, too.  Should be easy enough: 'if': 'CONFIG_FOO' in the QAPI
schema.

Except that makes the entire code QAPI generates for rocker.json
device-dependent: it now contains #if defined(CONFIG_ROCKER), and
CONFIG_ROCKER is poisoned.  The rocker code implementing monitor
commands also becomes device-dependent, because it includes generated
headers.  We compile all that per target for no sane reason at all.
That's why we don't actually disable the commands.

Not disabling them creates another problem: we have the commands always,
but their implementation depends on CONFIG_ROCKER.  So we provide stubs
that always fail for use when CONFIG_ROCKER is off.  Drawbacks: we
generate, compile and link useless code, and QAPI/QMP introspection is
less useful than it could be.

This isn't terrible.  It still annoys me.  I wonder whether Philippe's
work on having a single qemu-system binary could improve things here.

Comments?