Handling invalid value for functors returning integral types, when there exists no MC association

When there exists no MC association for a reconstructed particle and the user requests to tuple TRUEID (via trueid = F.MAP_INPUT(F.TRUEID, Relations)), we require an invalid value to book the column.

Currently the MAP_INPUT functor checks if a functor defines its "own invalid value" and returns that (see for example BKGCAT). If no "own invalid value" exists, then a null optional (std::nullopt) is returned and FunTuple decides on an invalid value invoking std::numeric_limits<T>::quite_Nan() for basic types. So for basic types:

• float or double this is completely fine as the invalid value is nan, an international standard.
• int, we run into a problem as it returns 0, which can be a valid value for some functors (e.g. BKGCAT).

From discussions with @graven, we have two options for handling invalid value for integral types:

• Option1: Impose that a functor, returning an integral type, provide an invalid value (Requires changes in Rec).
• Option2: Change the default invalid value to either std::numeric_limits<T>::lowest() or std::numeric_limits<T>::max() (Requires changes in Analysis/FunTuple).

However, in this week's DPA WP3 meeting, @pkoppenb worries about when functors are used in cuts (see attached image or minutes).

FYI: @erodrigu and @mferrill