use extended regular expressions in the test for std::regex

for some compilers (e.g., GCC < 4.9) the default is buggy and
opm-parser thus uses extended expressions...

thanks to [at]bska for digging this up!
Merge pull request #261 from andlaus/test_for_extended_regex

use extended regular expressions in the test for std::regex
Refine semantics of WCONHIST implementation

This commit splits Schedule::handleWCONProducer() into those parts
that are specific to the individual keywords (WCONHIST/matching and
WCONPROD/prediction) and those that are common to both.

In particular we introduce two new helper functions

    matchingProperties() and predictionProperties()

of which the first constructs a WellProductionProperties object
specific to matching semantics and the latter constructs a similar
object specifc to prediction.  In the case of WCONHIST, the well
always supports component rates at surface conditions ({O,W,G}RAT)
as well as liquid rate (LRAT) and (total) reservoir volume rate
(RESV).  The prediction mode keeps the existing semantics of not
supporting control modes for which the values have been defaulted.

The final helper, function producerProperties(), dispatches to
matchingProperties() or predictionProperties() depending on
handleWCONProducer()'s 'isPredictionMode' flag and handles the
record properties that are common to both WCONHIST and WCONPROD,
including whether or not to assign a new active control mode.

The end result is that handleWCONProducer() becomes a loop of
keyword data records that

  1) Determines the wells affected by a given record
  2) Determines whether or not the wells are OPEN
  3) Computes control mode properties (producerProperties())
  4) Assigns status and those properties to all affected wells

This approach reorders the well loop compared to the previous
implementation which computed separate WellProductionProperties for
each well.
Disable WCONHIST/GRAT non-existence test

Keyword WCONHIST always supports GRAT control mode, even when
defaulted.  The default value (zero) might not be very useful in a
simulation case but it's supported nonetheless.
*Properties(): Switch to vector<string> for control modes

Update mode iteration accordingly.

Suggested by: [at]joakim-hove
*Properties(): Rename control mode (enum) variable

Four characters (cmod) is less readable than "cmode".

Suggested by: [at] joakim-hove
Rename helper: matchingProperties() -> historyProperties()

This more clearly reflects its actual purpose.

Suggested by: [at] joakim-hove
historyProperties(): Add note on numerically zero defaults

This is a hint to a future maintainers that the subsequent control
modes are unconditionally supported.
historyProperties(): Extract BHP limit if not defaulted

This fixes a programming error introduced in the refactoring of
Schedule::handleWCONProducer() (commit 3889e92).  When there is a BHP
limit in WCONHIST, we obviously need the value specified in the input
deck.  The refactoring led to the limit being extracted only in the
prediction mode.

Pointy hat: [at] bska
Refactor WellProductionProperties manipulation code

This commit splits the creation of WellProductionProperties objects,
and especially the ad-hoc helper functions historyProperties()
and predictionProperties() out to a separate module,
WellProductionProperties.[hc]pp.  Creating the properties object
from a DeckRecordConstPtr is deferred to two named constructors,

    WellProductionProperties::history() and
    WellProductionProperties::prediction()

that, respectively, assume the roles of historyProperties() and
predictionProperties().  Reimplement handleWCONProducer() in terms
of these named constructors and remove the producerProperties()
helper whose task, inspecting the status and retrieving/setting the
CMODE if not SHUT, can be assumed by handleWCONProducer().

Add a simple test module, WellPropertiesTest.cpp, to enforce the
rather peculiar semantics of the WCONHIST keyword.  Control modes
{O,W,G}RAT, LRAT, and RESV are *always* (unconditionally) supported
in WCONHIST but there is no control mode switching.  The latter is
deferred to client code, depending on the '.predictionMode' flag.

Suggested by: [at] joakim-hove
Prediction mode: Support GRUP control

If a well is available for group control, we should add that control
mode to its Injection or ProductionProperties before assigning a new
current (active) control mode to the well ('.controlMode').

Suggested by: [at] joakim-hove.