RFC: rework the SchedulerRequirements, promote to draft state

including some consequences taken from last developer meeting
Clang(#928): fix inconsistencies and compilation problems

Compilation with Clang 3.0 (which is available in Debian/stable) fails,
mostly due to some scoping and naming inconsistencies which weren't detected
by GCC. At some instances, Clang seems to have problems to figure out a
perfectly valid type definition; these can be resolved by more explicit
typing (which is preferrable anyway)
Clang(#928): refactor OutputSlot implementation to resolve a scoping problem

Clang is more insistent when it comes to enforcing 'protected' visibility.
Since in this case the basic design can be considered sane and optimal, the
only (and obvious) solution is to nest the PIMPL into a default base class
for implementation; this mirrors the structure of the interface.
Clang-3.0(#932): workaround for a known problem of Clang-3.0 (Debian/stable)

http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20121203/069267.html

http://stackoverflow.com/questions/13521163/variadic-template-as-template-parameter-deduction-works-with-gcc-but-not-with-c

Clang aborts the template type deduction due to different size of the argument lists;
in fact the missmatching arguments can be filled in perfectly from the default template arguments.

As a workaround, we'll include an unused placeholder type parameter into the templated function,
to make the match succeed.
Clang(#928): fix re-entrance error in testcode

Clang seems to evaluate the terms of a function call in another order
than GCC -- this uncovered re-entrance errors in some metaprogramming tests,
where we re-used a global formatter object in recursive instantiations.
Clang(#928): clarify instantiation of dependent template

clang-3.2 requires a clarification here (while previous versions
of clang and GCC automatically resolved the ambiguity by assuming
use of a nested, dependent template).
bughunt: extract a call sequence leading to a strange init error with Clang

Observations:
 - the initial observation was that we get two instances of the config rules service
 - obviously this it is *not* the initialisation of a static variable accessed from
    multiple compilation units. But the access from two compilation units is crucial
 - we can exclude the effect of all other initialisation. It *is* in SingletonSubclass
 - we can exclude the effect of dynamic linking. Even two translation units
    linked statically exhibit the same problem

rebuild this test case in the research area, to be able to verify with various compilers
bughunt: build testcase statically linked

...but still dynamically linking against the core lib
But the actual template instantiations happen now within the two
compilation units, which are linked statically.

When looking into the symbol table, we can see that the static
field is emitted two times

readelf -W target/clang-static-init -s | c++filt |less
bughunt: replace the ConfigResolver with a direct instantiation of Singleton -> MISS

thus not lib::Singleton is the culprit, it must be lib::SingletonSubclass
bughunt: use a single SingletonSub instance in two compilation units --> HIT

basically this reproduces the problem in a simplified setup.
Especially note that we're going through a single instance of the factory,
yet still this single instance 'sees' two different locations of the
class static variable
bughunt: attempt to rebuild the problematic structure stand-alone... --> MISS

this is only a stripped-down version of the basic singleton, without
the indirection. Unsurprisingly, this doesn't exhibit the problem yet
bughunt: re-create the whole 2nd layer with a configurable product type --> HIT

Now we've reprduced the problematic situation in isolation
BUG: Clang shows a problem when accessing templated static variable through separate compilation units

this is really creepy: the same(!) instance of the singleton factory
sees different addresses of the class static variable, depending on
the compilation unit.

Please note that the type of the concrete factory function is *erased*
when exiting the constructor function of ConfigurableHolder
Build: adjust versions and naming to comply with Debian/Jessie

Note: this drops some backwards compatibility. We're targeting now
roughly the range between Ubuntu-Precise (LTS) and Debian/testing,
with Debian/stable as the reference system.

The naming scheme for Boost-Libraries was adjusted with Boost-1.42
for Unix-Platforms. Now the '-mt' suffix isn't included any more, but
the libraries available through the usual packaging mechanisms can be
assumed to be thread safe.

See also http://issues.lumiera.org/ticket/759
remove superfluous template parameter dependency
clean-up and comments for the singleton factory
investigation of a problem with Clang

posted also to Stackoverflow. http://stackoverflow.com/questions/19212474/clang-links-to-different-locations-when-referring-a-templated-static-variable-fr
DOC: switch on TOC and footnotes on some pages