FunTuple enhancements

This MR addresses #20 (closed) and more. Changes summarised below:

1. Bug fix related to multiple candidates (FYI @gunther and @mengzhen ).
2. Code generalisation for input type: @graven's comment does not work due to absence of overloaded methods of findDecay. However, inspired from this comment, have made some significant changes to code structure. As a result, FindAndBookTuple method is now split into two: find_candidates and write_tuple. The latter is fully templated and only the former now depends on input type (however can smoothly transition to v2::Composites when "finding" feature becomes available there).
   • Consequence of this on local tests: The restructuring has a consequence on the local tests that fail due to removal of generation of dummy particles inside FunTuple (this was planned and was also very restrictive). These local tests are anyway superseded by DV examples (at-least for LHCb::Particles). For LHCb::MCParticles plan to develop a dedicated example to read in xgen file (see #21 (closed)). These local tests are obsolete and removed.
3. Support ThOr functors that output std::map: Tupling of ThOr functor that output std::map<std::string, std::any> is supported. The use case was discussed in minutes of DPA WP3 meeting regarding dumping all HLT line decisions of the candidate. The minutes also suggests that @cprouve is interested in this for FT (?).
4. Support output from ParticleFiler: @sstahl suggested to replace LHCb::Particles -> LHCb::Particle::Range to be used for output from ParticleFilter (Reported use case by @mengzhen here).
5. Templating book_tuple (doesn’t work): @pkoppenb suggested to template book_tuple. It works for LoKi but not for ThOr. I guess this is related to the fact that if ThOr outputs directly std::any (without me explicitly doing this) there is no overloaded function to book it (TupleObj::column(const string&, const std::any&). So I have kept this as is, but open to ideas.
6. Custom error message handling: @graven's comment on custom error message handling there, however currently used only for counters. Will have to look into possible places to extend.
7. DEBUG messages and forward extra args to FunTuple: @erodrigu 's suggestion adding DEBUG features and general clean-up of code is done. Allow passing of extra arguments to FunTuple (e.g. OutputLevel, etc).

FYI: @mferrill and @powen