- move Gaudi::Funtional to GaudiFunctional subdir
  - headers are now under "Gaudi/Functional"
  - legacy GaudiAlg corresponding header redirect to the new ones
- replace GaudiAlgorithm with Algorithm wherever possible in tests and
  utilities
- add Gaudi::Sequencer basic implementation to replace GaudiSequencer
- move GaudiAlg specific tests, examples, dictionaries and Python modules
  to GaudiAlg subdir
- add CMake option GAUDI_ENABLE_GAUDIALG to allow skipping GaudiAlg
  (default to true)
- minor fixes and clean ups

Messages can be enabled by setting the `ENABLE_GAUDITOOL_SUMMARY`
environment variable.

Closes #215

so that things work in a super project build

Change the type of the properties used to specify the input / output locations of {Merging,Splitting}Transformer
from vector-of-string to the more appropriate vector-of-DataObjID

- and add a `#define` to simplify migration

Currenly, the constructors of the Gaudi::Functional baseclasses use
`std::array<KeyValue,N>` as arguments where N is the number of inputs
or outputs specified. However, this implies that one can specify a list
of less than N KeyValues, as `std::array` will happily
default-initialize any missing items. This will then result in an error
in genConf, as this implies a property with a default-initialized string
(i.e. an empty string) as key.

This can be fixed by replacing the `std::array<KeyValue,N>` with a tuple
with N `KeyValues, eg. for N=2 an `st::tuple<KeyValue,KeyValue>`.

* allow distinct types of columns to be filled in a single call

* avoid using C-style VA_ARGS which assumes 'double' arugments without any checking
* generalize to 'all the same type of arguments' instead of 'all double', and check
  at compile time
* avoid creating an `std::vector` to tokenize the format string

* remove one level of indirection in memory layout
* allow the use of std::string_view in find

* remove one redundant layer of indirection in the storage of the
  'value' -- items in a `std::unordered_map` are stable, so no need
  to store a `unique_ptr<T>`, and instead just store a `T` directly
  (as T is highly constraint already in order to be able to write it
  into an NTuple)
* make lookup by `std::string_view` instead of `std::string` as most
  usecases have a string literal (which is not an `std::string`) as
  argument, and in case of `std::string` this implies at least copying
  the characters, and (in case it overflows the SBO of `std::string`)
  a potential memory allocation

Based on the MultiMergingTransformer implementation, but allows for
algorithms to return a boolean which sets the 'filter passed' property
for the control flow.

A new test checks an example instantiation along one of
MultiMergingTransformer, which was not previously tested. To make this
test more obvious the IntDataProducer example now has a configurable
value property.