Simplify ebo_function_holder

[nkolotov]

Upon further inspection i've noticed that implementation of ebo_function_holder is extremely redundant. This class template has essentially two flavors:

• specialization for cases when T is a class type, inheriting from it, hopefully utilizing Empty Base Optimization
• specialization for cases when T is a pointer to function type, storing pointer as a field

Currently a fancy is_unary_or_binary_function trait is used to distinguish between these flavors, even though code only really cares whether it can inherit from T or not.

I've changed ebo_function_holder to specialize for T * instead. This allowed to

• get rid of defaulted third template parameter of ebo_function_holder which was used to store trait evaluation result
• get rid of is_unary_or_binary_function and is_unary_or_binary_function_impl classes since they were otherwise unused

Additionally i've removed

• constructor taking two arguments from specialization dealing with function pointer. Given that t_ is a pointer to function, initialization : t_(::boost::forward<Arg1>(arg1), ::boost::forward<Arg2>(arg2)) couldn't possibly be valid. Presumably it was a result of copypasta.
• a couple of unused includes of ebo_function_holder.hpp

I believe these changes preserve backward compatibility, except for cases when library users directly wrote detail::is_unary_or_binary_function in their code which they probably shouldn't have since it was not a part of public API.

[igaztanaga]

Thanks, it looks like a warning is triggered in MSVC 14.5 (C4180), so I tweaked a bit your patch and merge it to develop. Many thanks, it certainly simplifies a lot code and eases maintenance.