ENH: noiseModels - updated parallel usage (no longer needs proc dirs) and apply input data validation

- was generally somewhat fragile. The main problem stems from the fact
  that several interfaces may be attached to a boundary. No trivial
  means of solving this without too much work for a feature that is only
  "nice-to-have".

- Programming convenience.
  Eg, cos(45_deg) vs cos(degToRad(45))

STYLE: conversions marked as constexpr and noexcept

- the NamedEnum wrapper is somewhate too rigid.
  * All enumerated values are contiguous, starting as zero.
  * The implicit one-to-one mapping precludes using it for aliases.
  * For example, perhaps we want to support alternative lookup names for an
    enumeration, or manage an enumeration lookup for a sub-range.

- no penalty compared to Tuple2, potential future benefits with C++
  constructor forwarding.

- Remove the unused enums() method since it delivers wholly unreliable
  results. It is not guaranteed to cover the full enumeration range,
  but only the listed names.

- Remove the unused strings() method.
  Duplicated functionality of the words(), but was never used.

- Change access of words() method from static to object.
  Better code isolation. Permits the constructor to take over
  as the single point of failure for bad input.

- Add values() method

- do not expose internal (HashTable) lookup since it makes it more
  difficult to enforce constness and the implementation detail should
  not be exposed. However leave toc() and sortedToc() for the interface.

STYLE: relocated NamedEnum under primitives (was containers)

- internal typedef as 'value_type' for some consistency with STL conventions

- The unset() method never auto-vivifies, whereas the set() method
  always auto-vivifies. In the case where set() is called with a zero
  for its argument - eg, set(index, 0) - this should behave
  identically to an unset() and not auto-vivify out-of-range entries.

COMP: avoid undefined-var-template warning in runTimePostProcessing

BUG: foamToEnsight fails with missing field at time 0 (fixes #473)

- provides a summary hash of classes used and their associated object names.

  The HashTable representation allows us to leverage various HashTable
  methods. This hashed summary view can be useful when querying
  particular aspects, but is most useful when reducing the objects in
  consideration to a particular subset. For example,

      const wordHashSet interestingTypes
      {
          volScalarField::typeName,
          volVectorField::typeName
      };

      IOobjectList objects(runTime, runTime.timeName());
      HashTable<wordHashSet> classes = objects.classes();

      classes.retain(interestingTypes);

      // Or do just the opposite:
      classes.erase(unsupportedTypes);

  Can also use the underlying HashTable filter methods

STYLE: use templated internals to avoid findString() when matching subsets

- Generalized means over filtering table entries based on their keys,
  values, or both.  Either filter (retain), or optionally prune elements
  that satisfy the specified predicate.

  filterKeys and filterValues:
  - Take a unary predicate with the signature

        bool operator()(const Key& k);

  - filterEntries:
    Takes a binary predicate with the signature

        bool operator()(const Key& k, const T& v);

==

  The predicates can be normal class methods, or provide on-the-fly
  using a C++ lambda. For example,

      wordRes goodFields = ...;
      allFieldNames.filterKeys
      (
          [&goodFields](const word& k){ return goodFields.match(k); }
      );

  Note that all classes that can match a string (eg, regExp, keyType,
  wordRe, wordRes) or that are derived from a Foam::string (eg, fileName,
  word) are provided with a corresponding

      bool operator()(const std::string&)

  that either performs a regular expression or a literal match.
  This allows such objects to be used directly as a unary predicate
  when filtering any string hash keys.

  Note that HashSet and hashedWordList both have the proper
  operator() methods that also allow them to be used as a unary
  predicate.

- Similar predicate selection with the following:
    * tocKeys, tocValues, tocEntries
    * countKeys, countValues, countEntries

  except that instead of pruning, there is a simple logic inversion.

- predicates::always and predicates::never returning true and false,
  respectively. These simple classes make it easier when writing
  templated code.

  As well as unary and binary predicate forms, they also contain a
  match(std::string) method for compatibility with regex-based classes.

STYLE: write bool and direction as primitive 'int' not as 'label'.

- ensure that the string-related classes have consistently similar
  matching methods. Use operator()(const std::string) as an entry
  point for the match() method, which makes it easier to use for
  filters and predicates. In some cases this will also permit using
  a HashSet as a match predicate.

regExp
====
- the set method now returns a bool to signal that the requested
  pattern was compiled.

wordRe
====
- have separate constructors with the compilation option (was previously
  a default parameter). This leaves the single parameter constructor
  explicit, but the two parameter version is now non-explicit, which
  makes it easier to use when building lists.

- renamed compile-option from REGEX (to REGEXP) for consistency with
  with the <regex.h>, <regex> header names etc.

wordRes
====
- renamed from wordReListMatcher -> wordRes. For reduced typing and
  since it behaves as an entity only slightly related to its underlying
  list nature.

- Provide old name as typedef and include for code transition.

- pass through some list methods into wordRes

hashedWordList
====
- hashedWordList[const word& name] now returns a -1 if the name is is
  not found in the list of indices. That has been a pending change
  ever since hashedWordList was generalized out of speciesTable
  (Oct-2010).

- add operator()(const word& name) for easy use as a predicate

STYLE: adjust parameter names in stringListOps

- reflect if the parameter is being used as a primary matcher, or the
  matcher will be derived from the parameter.
  For example,
      (const char* re), which first creates a regExp
      versus (const regExp& matcher) which is used directly.

- This makes the following safe:

      auto iter = ptrTable.find(unknownKey);
      ptrTable.erase(iter);

- Unmask HashPtrTable::erase(const Key& key) method

ENH: ensure std::distance works with hashtable iterators

- inherit from std::iterator to obtain the full STL typedefs, meaning
  that std::distance works and the following is now possible:

      labelRange range(100, 1500);
      scalarList list(range.begin(), range.end());

  --
  Note that this does not work (mismatched data-types):

      scalarList list = identity(12345);

  But this does, since the *iter promotes label to scalar:

      labelList ident = identity(12345);
      scalarList list(ident.begin(), ident.end());

  It is however more than slightly wasteful to create a labelList
  just for initializing a scalarList. An alternative could be a
  a labelRange for the same purpose.

      labelRange ident = labelRange::identity(12345);
      scalarList list(ident.begin(), ident.end());

  Or this
      scalarList list
      (
          labelRange::null.begin(),
          labelRange::identity(12345).end()
      );

- provides const/non-const access to the underlying list, but the
  iterator access itself is const.

- provide linked-list iterator 'found()' method for symmetry with
  hash-table iterators. Use nullptr for more clarity.

- lookup(): with a default value (const access)
  For example,
      Map<label> something;
      value = something.lookup(key, -1);

    being equivalent to the following:

      Map<label> something;
      value = -1;  // bad value
      if (something.found(key))
      {
          value = something[key];
      }

    except that lookup also makes it convenient to handle const references.
    Eg,

      const labelList& ids = someHash.lookup(key, labelList());

- For consistency, provide a two parameter HashTable '()' operator.
  The lookup() method is, however, normally preferable when
  const-only access is to be ensured.

- retain(): the counterpart to erase(), it only retains entries
  corresponding to the listed keys.

  For example,
      HashTable<someType> largeCache;
      wordHashSet preserve = ...;

      largeCache.retain(preserve);

    being roughly equivalent to the following two-stage process,
    but with reduced overhead and typing, and fewer potential mistakes.

      HashTable<someType> largeCache;
      wordHashSet preserve = ...;

      {
          wordHashSet cull(largeCache.toc()); // all keys
          cull.erase(preserve);               // except those to preserve
          largeCache.erase(cull);             //
      }

  The HashSet &= operator and retain() are functionally equivalent,
  but retain() also works with dissimilar value types.

- less clutter and typing to use the default template parameter when
  the key is 'word' anyhow.

- use EdgeMap instead of the longhand HashTable version where
  appropriate

- the heuristic for matching unresolved intersections is a relatively
  simple matching scheme that seems to be more robust than attempting to walk
  the geometry or the cuts.

- avoid false positives for self intersection

Henry Weller authored 7 years ago and Andrew Heather committed 7 years ago

Also added support for extrapolated pressure boundary conditions.

- provide key_iterator/const_key_iterator for all hashes,
  reuse directly for HashSet as iterator/const_iterator, respectively.

- additional keys() method for HashTable that returns a wrapped to
  a pair of begin/end const_iterators with additional size/empty
  information that allows these to be used directly by anything else
  expecting things with begin/end/size. Unfortunately does not yet
  work with std::distance().

  Example,
     for (auto& k : labelHashTable.keys())
     {
        ...
     }