[Rivet] bug: RivetSTL conflicts with LHAPDF includes

[Dmitry Kalinkin]

Dear Rivet developers,

I’ve encountered a bug that prevents me from using both Rivet and LHAPDF includes in one file:
% cat test.cpp                                                                                                                                                                                                      :(
#include <Rivet/AnalysisHandler.hh>
#include <LHAPDF/LHAPDF.h>

% gcc test.cpp `rivet-config --cppflags` `lhapdf-config --cppflags`              
In file included from lhapdf/6.1.5/include/LHAPDF/Info.h:10:0,
                 from lhapdf/6.1.5/include/LHAPDF/PDFInfo.h:10,
                 from lhapdf/6.1.5/include/LHAPDF/PDF.h:10,
                 from lhapdf/6.1.5/include/LHAPDF/LHAPDF.h:14,
                 from test.cpp:2:
lhapdf/6.1.5/include/LHAPDF/Utils.h: In function 'std::__cxx11::string LHAPDF::operator/(const string&, const string&)':
lhapdf/6.1.5/include/LHAPDF/Utils.h:111:30: error: call of overloaded 'contains(std::__cxx11::string&, const char [3])' is ambiguous
     while (contains(rtn, "//"))
                              ^
lhapdf/6.1.5/include/LHAPDF/Utils.h:70:15: note: candidate: bool LHAPDF::contains(const string&, const string&)
   inline bool contains(const std::string& s, const std::string& sub) {
               ^
In file included from rivet/2.4.0/include/Rivet/Config/RivetCommon.hh:45:0,
                 from rivet/2.4.0/include/Rivet/AnalysisHandler.hh:5,
                 from test.cpp:1:
rivet/2.4.0/include/Rivet/Tools/RivetSTL.hh:95:15: note: candidate: bool std::contains(const string&, const string&)
   inline bool contains(const string& s, const string& sub) {
               ^
<and so on>

This also reproduces with clang.

I’ve tried to isolate the issue, but couldn’t get to the root of it. There extension of std:: in RivetSTL.hh is questionable and this is one possible point for fix. On the other hand LHAPDF/Utils.h could be fixed as it has "using namespace std;”, but for some reason replacing it with explicit "std::" doesn’t solve the problem. It seems to me that the fastest way to tackle this would be to fix Rivet (e.g. wrap mili functions into mili:: as done in https://bitbucket.org/fudepan/mili/src/a8ade229696cfae66f55121222dd95594cfae276/mili/mili.h?at=default&fileviewer=file-view-default#mili.h-32 ).

Cheers,
Dmitry