cleanup: remove the old factory template

This template was a leftover from the early days
of Lumiera development and doesn't provide any
substantial value as an abstraction.

For the more intricate cases, we're using the
lib::MultiFact template, which allows to install
several "fabrication" functions at runtime
switch off enum warning for now (#898)
prepare refactoring of the Query interface
move Query interface to Lib
adjustments and stubbing to get it past the compiler
re-arrange query- rules- and resolver facilities within Core

the rules-based configuration and query system
will be located within the core application,
while the concrete implementation facilities
are expected to reside within the session or
maybe also the GUI.

This is kind of a 'rochade' refactoring to resolve
circular library dependencies and confine the parts
dependant on the session and MObjects to the Proc-Layer

And while we're in the middle of chainsaw surgery,
we'll concentrate further query-based facilities
alongside the config-rules within the App core.
create a new integration point for using application services

especially this allows to use the Advice system
or the query resolvers from within library facilities
to refer to other implementation level services by name
refactor namespaces for query and defaults manager
provide a time mutation for nudging based on symbolic grid reference

time handling is part of the library, while this
convenience shortcut relies on the Advice system,
which resides in the application lib.
To allow this kind of symbolic acces to a grid
entity defined "elesewhere", client code needs
to be linked against liblumieracore.so
clean-up and finalise time::Mutation
refactor use of HashVal typedef (#722)
bring the plain query utilities back into lib
fix includes
generic query representation (placeholder)

...planned to be replaced later by a real
AST based implementation, which acutally
parses the query definitions
integrate (placeholder) query definition

effectively this joins the two existing lines
of "Query" classes into one systematic representation
Next step would be to move all mutation operations
over to the Query::Builder
implement builder/accesor function; adapt StructFactory
factor out fequently used functions for ordinal numbers
implement another builder function; adapt OutputDesignation
WIP extend query with a warpper for indexing and ordering

...to extract the syntetic ordering from
DefsRegistry and make that a responsibility
of the (internal) syntactic representation
of the query.

doesn't pass the compiler yet
refactor defaults-manager to use the reworked query interface