Some configuration scripts probe and just set HAVE_FOO without any
values, whereas others set it explicitly to 1. If these two are mixed,
for instance that the same package is used by two of our prerequisites,
but in different manner, then we get compatibility warnings when we try
to run the configuration script, even though there is no real conflict.
dune-fem, dune-alugrid and dune-localfunctions have this problem (around
release 2018.04).
This patch special-code the test so if the old value was previously
either just defined or explicitly set to the value 1, a warning will not
be issued if then suddenly the other variant is used.
newer versions of cmake (mine is 3.2.2) complain about policy CMP00054:
```
CMake Warning (dev) at /home/and/src/opm-common/cmake/Modules/ConfigVars.cmake:30 (if):
Policy CMP0054 is not set: Only interpret if() arguments as variables or
keywords when unquoted. Run "cmake --help-policy CMP0054" for policy
details. Use the cmake_policy command to set the policy and suppress this
warning.
Quoted variables like "FILE" will no longer be dereferenced when the policy
is set to NEW. Since the policy is not set the OLD behavior will be used.
Call Stack (most recent call first):
/home/and/src/opm-common/cmake/Modules/OpmLibMain.cmake:173 (configure_vars)
CMakeLists.txt:109 (include)
This warning is for project developers. Use -Wno-dev to suppress it.
```
since I'm pretty sure that the old behaviour was not intended here,
fix this for older versions of cmake as well (by adding a prefix so that
CMake does not interpret "FILE" as a variable.)
