- Now that the metisDecomp uses the metis definition for float/double,
  do not need to verify the scalar sizes.

Note:
- could drop precision qualifier for metis, scotch installation
  (include, lib) as being unneeded, but it is simpler to keep them
  and continue to use the FOAM_EXT_LIBBIN path
  (in case other ThirdParty software is compiled with different
  precisions).

- since Icc is actually mentioned in bashrc/cshrc it is consistent to
  set these values accordingly.

- Cannot test if these older reader modules actually build,
  owning largely to build issues since with paraview 3.14 (Feb 2012)
  and paraview 3.98 (Dec 2012) themselves.

- Follow similar pattern as per boost/CGAL with the '*-none' to disable,
  and '*-system' for system installations.

  Also support central non-ThirdParty installations by specifying the
  version as "*-system", but also providing the fully qualified
  *_ARCH_PATH too.

--
ENH: Verify label and scalar sizes used in the metis header.

- ensure they match with expected values, which can be obtained via
  the OpenFOAM definitions for WM_LABEL_SIZE and WM_PRECISION_OPTION

On 64-bit systems, the system installations of boost, cgal are under
lib64/. The behaviour for a ThirdParty build is mostly lib/ but this
can also be changing.

    Boost 1_62_0 and older build into 'lib/'.
    CGAL-4.9 builds into 'lib64/', older versions into 'lib/'.

Future-proof things by using lib$WM_COMPILER_LIB_ARCH for boost and
cgal build rules, and forcing these as build targets in the ThirdParty
makeCGAL as well.

--
STYLE: check for boost/version.hpp, CGAL/version.h instead their directories

- On the first call, ParaView_DIR is unset and thus the clean-path
  fails with the warning "ParaView_DIR: Undefined variable."

  This looks messy, but is of no _major_ consequence since paraview
  doesn't need to be removed anyhow. The only slight risk is that the
  path to a third-party cmake might not be cleaned.

- Patch as per Bruno's suggestion.

- It is incorrect to prefix the assignment with an 'export' since this
  automatically marks the overall command as successful and circumvents
  the fallback.

  There is no simple way to have proper behaviour when sourced with a
  local directory path, but at least it now uses the fallback.

  It is still easy to wreak the mechanism with valid but confusing input.
  For example,

     ". /path/to/openfoam/etc/././bashrc"

  The only real certainty is that "${BASH_SOURCE%/*}"
  should point to the 'etc/' directory. In which case,

      cd ${BASH_SOURCE%/*}    # <- now in the etc/ directory
      pwd=$(pwd -P)           # <- fully-qualified path to etc/
      pwd=${pwd%/*/*}         # <- up two parent levels

  - This works with ". ./bashrc", but fails with ". bashrc"
    (probably not so common).
  - Con: The construct requires an additional sub-shell.

- In the foundation version they introduced a construct to handle
  the transition from 'wmRefresh' as an alias to 'wmRefresh' as
  a shell function. This transition is unnecessary for OpenFOAM+
  since 1606 used wmREFRESH (not wmRefresh) as an alias.

  For portability it is important to avoid this non-POSIX
  "type -t". It causes issues with dash and with zsh
  (mentioned in issue #277).

        type -t dash  ->   -t: not found
        type -t zsh   ->  zsh: bad option: -t

Note: zsh users may still noticed other problems.
For example, the POSIX 'unset -f' normally has no output, but in zsh
it reports an error and has exit code 1 if the function was not
previously defined. Whereas in POSIX (including bash, dash) it only
returns non-zero if the name(s) could not be unset.

Patch contributed by Bruno Santos
Resolves bug-report http://bugs.openfoam.org/view.php?id=2285

- instead we use the CGAL settings directly since they have the
  same option of (version | system | none)

- may wish to review this again in the future.

Patch provided by Mattijs Janssens
Resolves bug-report http://bugs.openfoam.org/view.php?id=2240

Patch provided by Bruno Santos
Resolves bug-report http://bugs.openfoam.org/view.php?id=2051

Resolves bug-report http://bugs.openfoam.org/view.php?id=2223

  - "$FOAM_USER_APPBIN" and "$FOAM_USER_LIBBIN" have been added to
    "foamOldDirs" in "etc/bashrc" and "etc/config.sh/unset"

  - "$OPAL_PREFIX" is now undefined in the option "SYSTEMOPENMPI" within
    "etc/config.sh/mpi", but only if the path defined in this variable
    is cleaned when using "foamCleanPath".

  - "$OPAL_PREFIX" is now also conditionally undefined in
    "etc/config.sh/unset" when the path is picked up by "foamCleanPath".

Patch contributed by Bruno Santos
Resolved bug-report http://bugs.openfoam.org/view.php?id=2210

surfaceRegion will be the name of a class to provide support for surface
region selection.

Renamed the original volRegion -> volFieldValue to clarify the purpose
of this class to process vol fields on a volRegion.

The change from C++0x to C++11 allows all of C++11 functionality to be
used in OpenFOAM, in particular constructor delegation which avoids code
duplication or constructor helper functions.  However, this also means a
change to the minimum gcc version supported which is now 4.7 rather than
4.5.

Note that gcc-4.7 does not support the entire C++11 standard but does
support all of the functionality currently needed for further OpenFOAM
development.  The minimum gcc-version which supports the entire C++11
standard is 4.8 which is now the recommended minimum gcc version.

- these frontends are defunct and their formats were quite a mess.
  Prostar 4 versions (star4ToFoam, foamToStarMesh) should be used
  instead.

Now reduced to 3 environment variables:
    ParaView_DIR         - paraview installation directory
    ParaView_INCLUDE_DIR - paraview include directory
    PV_PLUGIN_PATH       - paraview plugin directory for OpenFOAM modules

Previously also had (ParaView_MAJOR, ParaView_VERSION).

ThirdParty makeParaView adjusted accordingly.

ENH: improved configuration possibility for non-ThirdParty paraview
installation.

BUG: csh foamPV alias was completely incorrect.

- export/setenv WM_COMPILER_TYPE as suggested by Mattijs.

- for overall consistency, don't carp about an unset WM_COMPILER_TYPE,
  since this would only be on the first instance (prior to the
  export/setenv) and would be confusing about why/when this message
  may occur.

- reduce clutter: only use (system|ThirdParty) for WM_COMPILER_TYPE.
  Drop the old 'OpenFOAM' setting for WM_COMPILER_TYPE, which was
  transitional in early 2011.

- make the error messages more meaningful

- many systems may not have boost or FFTW installed, or in an older
  version. Using ThirdParty for them should lead to a more robust
  build process.

- triggered by dash.

- gcc/g++ always being used

STYLE: spurious unsetenv WM_COMPILER_TYPE (csh only)

- more stringent cleanup of ThirdParty settings for wmUNSET