RFC: "once" FIXME capability

[Erich E. Hoover]

While at LinuxTag Sebastian Lackner, Michael Müller, and I were
chatting with Michael Stefaniuc and Anastasius Focht about the way we
currently implement "one-time FIXME".  It was discussed that a more
global approach to this was desired, but that it should have the
following characteristics:

1) It should work with ANSI C compilers (the variadic macro problem)
2) It should be something that we can disable with a debug channel
(something AF would really appreciate that our current ad-hoc approach
does not support)
3) It should be expandable to handling a "once per flag" capability

Toward that end the three of us have put together several proposed
"once" implementations.  All three patch-sets are based on variations
of the following trick to allow defining in-place static variables
without any special compiler requirements:
if(1) { \
    static int __wine_debug_once = 0; \
    int __wine_debug_once_temp = __wine_debug_once; \
    if(!__wine_debug_once) __wine_debug_once = 1; \
    if(__wine_debug_once_temp == 0) \
        goto __WINE_LIMIT_LABEL(__LINE__); \
} else __WINE_LIMIT_LABEL(__LINE__):

Here are the various approaches:
1) https://dl.dropboxusercontent.com/u/195059/wine/WineOnce_1.tgz
This implementation is a macro (LIMIT_ONCE, LIMIT_FLAG_ONCE) that you
would use to prefix a FIXME/WARN/etc.  The feature can be disabled by
enabling the "+nolimit" WINEDEBUG option (patch 3).
2) https://dl.dropboxusercontent.com/u/195059/wine/WineOnce_2.tgz
This implementation builds onto the existing FIXME to add a FIXME_ONCE
(and FIXME_FLAG_ONCE).  The feature can be disabled by enabling the
"+nolimit" WINEDEBUG option (patch 4).
3) https://dl.dropboxusercontent.com/u/195059/wine/WineOnce_3.tgz
This implementation builds onto the existing FIXME to add a FIXME_ONCE
(and FIXME_FLAG_ONCE).  The feature can be disabled by enabling the
"nolimit+<channel>" WINEDEBUG option (patch 4).  This version benefits
from the ability to turn off limiting on a per-channel basis, which
should make it easier to track down problems when an unrelated debug
channel is also spamming the console.

We'd love to hear which approach everyone likes the most or any
feedback you might have.

Best,
Erich