Make GCC 4.6.3 happy in C++0x mode

It complains about not finding a match for the pair<> template class,
because the first parameter (this) is allegedly const. However, this
isn't a const method, so I suspect it is a compiler bug.

In order to move on, I slap on a harmless cast which will make this
particular compiler happy, and which should have no effects elsewhere,
but put it in a #if..#else..#endif macro to avoid warnings on others;
hopefully this also makes it easier to spot and remove in the future.
Merge pull request #81 from rolk/pair0x

Make opm-core compilable in C++0x mode on Ubuntu Precise
Add macros for testing C++0x/11 support in compiler

These files are shamelessly ripped from dune-common/m4 (e28ca3)
Distinguish between C++0x and C++11 in conf. opts.

Surely this must have been a copy&paste error.
Compile with C++0x support if possible

Since DUNE does this, it might a good idea to track the same ABI.
Disable checks for C++11 if C++0x is disabled

By adding an extra test we can avoid the somehow illogical possibility
of building with '--enable-gxx11check --disable-gxx0xcheck'.
Refrain from using reserved names ac_* for variables
Replace deprecated AC_TRY_COMPILE with AC_COMPILE_IFELSE
Recommend parallel builds

Load average of 0.9 is something that even a PhD student's crappy
laptop computer should be able to handle, without completely killing
it.

It really should be something like:

 make -j -l $(echo \($(grep "^processor" /proc/cpuinfo)+1\)\*0.9 | bc)

but that is probably far too complex to put in a README. The average
developer should be able to pick a reasonable value themselves.
Warn that OPM should not be built differently from DUNE.

Using headers and libraries from a DUNE built with different options
than OPM, can result in strange ABI errors such as a segmentation
fault in the static initialization section.
Merge pull request #83 from rolk/recommends

Update recommendations for building OPM
Replace !(a==b) test with a more common a!=b test
Fix well classification that was only correct by accident

Specifically, the tests

   if (!wells->type[self_index] == INJECTOR)
   if (!wells->type[self_index] == PRODUCER)

produced the expected results *only* because INJECTOR==0 and PRODUCER==1
in the WellType enumeration, thus (!INJECTOR == PRODUCER) and
(!PRODUCER == INJECTOR).

Installing the (much) more appropriate

    if (wells->type[self_index] != INJECTOR)
    if (wells->type[self_index] != PRODUCER)

is not only more readable, it is also future-proof and scales better if
we ever introduce new WellTypes (e.g., a MONITOR).
Remove superfluous construction by std::make_pair

Since we know the type of the components, we may just as well create the
pair directly! (Using make_pair invokes compiler bugs in GCC).
Merge pull request #82 from rolk/cxx0x

Build opm-core with C++0x support if available
Don't use '==' when '=' is equally good

There is no need to use Bash-specific operators when the pure sh(1)
built-in test operators have the exact same semantics.  This increases
portability to systems for which /bin/sh is *not* Bash (or Dash).
Merge pull request #85 from bska/use-standard-sh-in-ac

Don't use '==' when '=' is equally good
Merge pull request #84 from bska/fix-equality-comparisons

Fix well classification that was only correct by accident
Add constructor taking file name to GridManager.

Calls read_grid(). Grid fileformat not yet documented.
Added new tof computation utility.

This program assumes that grid, porosity, flux field and sources are
available to read from files. It does not compute any flux field itself.