Conditions reac

This is the branch that proposes a new API to deal with differences in chemical conditions and solves the thread safety problem (issue #58), right now only temperature and particle flux(es) are managed, generalization to multi-temperature, catalysis, any other stuff is easy by design.

It's quite big but there's (not so?) much to it.  

The global view is that instead of passing down a _const StateType & T_ from _KineticsEvaluator_ to the kinetics models (Arrhenius, Kooij and consorts), it passes down a _KineticsConditions_ object, which provides to the kinetics rate the right conditions (temperature or particle flux), the fork being made at the _KineticsType_ level, the base object to the rate constant calculators.
This _KineticsConditions_ object stores pointers to the conditions, either provided by the user himself
```
ChosenScalarType T = chosen_value_of_temperature;
ParticleFlux<ChosenVectorType> pf(wavelengths,irradiance);

... stuff to know what is the index of the photo reaction ...

KineticsConditions<ChosenScalarType,ChosenVectorType> kin_cond(T);
kin_cond.add_particle_flux(pf,index_of_concerned_photo_reaction);
```
or automatically generated by the _KineticsEvaluator_ to ensure backward compatibility.  I've found a not too expensive way: it either copies a reference or initializes the _KineticsConditions_ object.  Thus the changes in the _kinetics_evaluator.h_ file.
the meta funny structure _constructor_or_reference_ does very exactly what its name implies: if the two templates arguments are the same, it sends back a reference to the type, if not it sends back the type:
```
template<typename T1, typename T2>
struct constructor_or_reference
{
   typedef T1 type;
};

template <typename T>
struct constructor_or_reference<T,T>
 {
   typedef T & type;
 };
```

The biggest part of the changes are the photochemistry handling, in particular the rebinning phase.  Things to be aware are the new utilities functions _conjunction_,  _disjunction_ and _eval_index_, I expect them to be slow for anything other than Eigen, I haven't found a proper method for VexCl and metaphysicL (maybe I haven't been looking hard enough, I'm not sure).

This rebinning part is fully vectorized, sadly slow and I still consider as an almost bug that it recomputes the rate constant whatever happens, even if it does not change.  Good news is I have a few ideas playing with the _KineticsConditions_, though it needs better testing.

As photochemistry is not really essential right now, I think it's ok to proceed.
Do we ever want to do this? I'd make this private and force the user to provide a temperature to construct it.