- now defaults to the project-version when absolutely nothing else is
  known

STYLE: simplify internal calling in wmakeBuildInfo

- provide default WM_DIR if not already set, to improve robustness if a
  reduced environment is used

- add etc/ to WM_PROJECT_SITE search. This makes the site directory
  structure consistent with the OpenFOAM structure.
  Eg,

      WM_PROJECT_SITE/etc/..
      WM_PROJECT_SITE/bin/..
      WM_PROJECT_SITE/platforms/..

- Don't set/export WM_OSTYPE.  The default is POSIX and is properly
  defaulted throughout, including in CMakeLists-OpenFOAM.txt (also for
  Catalyst)

- Use the OPENFOAM define (eg, 1806, 1812), which normally corresponds
  to a major release, to define an API level. This remains consistent
  within a release cycle and means that it is possible to manage
  several sub-versions and continue to have a consistent lookup.

  The current API value is updated automatically during the build
  and cached as meta data for later use, even when the wmake/ directory
  is missing or OpenFOAM has not yet be initialized.

  The version information reported on program start or with -help
  usage adjusted to reflect this. The build tag from git now also
  carries the date as being more meaningful to trace than a hash
  value.

- Update etc/bashrc and etc/cshrc to obtain the project directory
  directly instead of via its prefix directory. The value obtained
  corresponds to an absolute path, from which the prefix directory
  can be obtained.

  The combination of these changes removes the reliance on any
  particular directory naming convention.
  For example,

     With an 1812 version (API level):

     WM_PROJECT_VERSION=myVersion

     installed as /some/path/somewhere/openfoam-mySandbox

  This makes the -prefix, -foamInstall, -projectVersion, -version
  values of foamEtcFiles, and similar entries for foamConfigurePaths
  superfluous.

  WM_PROJECT_INST_DIR is no longer required or used

ENH: improve handling and discovery of ThirdParty

- improve the flexibility and reusability of ThirdParty packs to cover
  various standard use cases:

    1. Unpacking initial release tar files with two parallel directories
       - OpenFOAM-v1812/
       - ThirdParty-v1812/

    2. With an adjusted OpenFOAM directory name, for whatever reason
       - OpenFOAM-v1812-myCustom/
       - openfoam-1812-other-info/

    3. Operating with/without ThirdParty directory

  To handle these use cases, the following discovery is used.

  Note PROJECT = the OpenFOAM directory `$WM_PROJECT_DIR`
       PREFIX = the parent directory
       VERSION = `$WM_PROJECT_VERSION`
       API = `$WM_PROJECT_API`, as per `foamEtcFiles -show-api`

   0. PROJECT/ThirdParty
      - for single-directory installations

   1. PREFIX/ThirdParty-VERSION
      - this corresponds to the traditional approach

   2. PREFIX/ThirdParty-vAPI
      - allows for an updated value of VERSION (eg, v1812-myCustom)
        without requiring a renamed ThirdParty. The API value
        would still be '1812' and the original ThirdParty-v1812/
        would be found.

   3. PREFIX/ThirdParty-API
      - this is the same as the previous example, but using an unadorned
        API value. This also makes sense if the chosen version name also
        uses the unadorned API value in its naming
        (eg, 1812-patch190131, 1812.19W03)

   4. PREFIX/ThirdParty-common
      - permits maximum reuse for various versions, but only for
        experienced user who are aware of potential version
        incompatibilities

   Directory existence is checked as is the presence of an Allwmake file
   or a platforms/ directory. This reduces the potential of false positive
   matches and limits the selection to directories that are either
   with sources (has the Allwmake file), or pre-compiled binaries (has
   the platforms/ directory).

   If none of the explored directories are found to be suitable,
   it reverts to using a PROJECT/ThirdParty dummy location since
   this is within the project source tree and can be trusted to
   have no negative side-effects.

ENH: add csh support to foamConfigurePaths

- this removes the previously experienced inconsistence in config file
  contents.

REMOVED: foamExec

- was previously used when switching versions and before the
  bashrc/cshrc discovery logic was added. It is now obsolete.

- append the commit hash value with the commit date when creating
  the build string information and drop the version prefix.

  This provides an immediate overview of when the code was last
  changed. The prefixed version information can be dropped from
  the build string, since it is readily available in other forms.

- removed reliance on ParaView_INCLUDE_DIR variable for conveying the
  major.minor version information when compiling. This can be somewhat
  fragile and also adds variable that is an unnecessary when running
  (only used when compiling).

  Instead use `have_pvplugin_support` function in paraviewFunctions
  wmake script to determine the maj.min from the PV_PLUGIN_PATH
  since we have already defined the output path there with paraview
  maj.min numbering.

  Can now build with paraview from the operating system,
  provided that it has develop headers available.

      ParaView_VERSION=system

  In the etc/config.sh/paraview setup, the maj.min is taken from
  the corresponding `paraview --version` output and used when
  defining the PV_PLUGIN_PATH.

  During the build, the include path taken from `paraview-config`
  for a system installation, from the guess installation root
  of the paraview binary, or ParaView_DIR otherwise.

NB: using a system ParaView for building runTimePostProcessing is unsupported.

- these types of builds appear to have various library resolution issues
  (eg, libexpat not being loaded). Additionally, the build logic does
  not yet cover this type of use case.

- if FOAM_EXT_LIBBIN is unset and some scripts set this to /usr/lib*
  as a fallback (eg, to avoid an undefined value) this will cause a
  system library to be found before appropriate *_ARCH_PATH entry.

  This was noticed during a scotch compilation without third-party:
  resulting in the system library (/usr/lib64/libscotch.so) to be found
  instead of the SCOTCH_ARCH_PATH location
  (/usr/lib64/mpi/gcc/openmpi/lib64/).

  Simply changing the search order doesn't work for use, since we wish
  to retain a preference for any dynamic libraries discovered in a
  real FOAM_EXT_LIBBIN.

  Circumvent these issues by only taking libraries from
  FOAM_EXT_LIBBIN if it also points to a location within ThirdParty.

- convenient when bootstrapping some systems

- local token shifting was missing when getting the next file chunk
  (while in the middle of parsing that text).

  As well as adding the correct shifting, also tag the local buffer
  with nullptr when it is done. Be extra paranoid and check the
  raw buffer range before passing off to std::string.

Previously the coordinate system functionality was split between
coordinateSystem and coordinateRotation. The coordinateRotation stored
the rotation tensor and handled all tensor transformations.

The functionality has now been revised and consolidated into the
coordinateSystem classes. The sole purpose of coordinateRotation
is now just to provide a selectable mechanism of how to define the
rotation tensor (eg, axis-angle, euler angles, local axes) for user
input, but after providing the appropriate rotation tensor it has
no further influence on the transformations.

--

The coordinateSystem class now contains an origin and a base rotation
tensor directly and various transformation methods.

  - The origin represents the "shift" for a local coordinate system.

  - The base rotation tensor represents the "tilt" or orientation
    of the local coordinate system in general (eg, for mapping
    positions), but may require position-dependent tensors when
    transforming vectors and tensors.

For some coordinate systems (currently the cylindrical coordinate system),
the rotation tensor required for rotating a vector or tensor is
position-dependent.

The new coordinateSystem and its derivates (cartesian, cylindrical,
indirect) now provide a uniform() method to define if the rotation
tensor is position dependent/independent.

The coordinateSystem transform and invTransform methods are now
available in two-parameter forms for obtaining position-dependent
rotation tensors. Eg,

      ... = cs.transform(globalPt, someVector);

In some cases it can be useful to use query uniform() to avoid
storage of redundant values.

      if (cs.uniform())
      {
          vector xx = cs.transform(someVector);
      }
      else
      {
          List<vector> xx = cs.transform(manyPoints, someVector);
      }

Support transform/invTransform for common data types:
   (scalar, vector, sphericalTensor, symmTensor, tensor).

====================
  Breaking Changes
====================

- These changes to coordinate systems and rotations may represent
  a breaking change for existing user coding.

- Relocating the rotation tensor into coordinateSystem itself means
  that the coordinate system 'R()' method now returns the rotation
  directly instead of the coordinateRotation. The method name 'R()'
  was chosen for consistency with other low-level entities (eg,
  quaternion).

  The following changes will be needed in coding:

      Old:  tensor rot = cs.R().R();
      New:  tensor rot = cs.R();

      Old:  cs.R().transform(...);
      New:  cs.transform(...);

  Accessing the runTime selectable coordinateRotation
  has moved to the rotation() method:

      Old:  Info<< "Rotation input: " << cs.R() << nl;
      New:  Info<< "Rotation input: " << cs.rotation() << nl;

- Naming consistency changes may also cause code to break.

      Old:  transformVector()
      New:  transformPrincipal()

  The old method name transformTensor() now simply becomes transform().

====================
  New methods
====================

For operations requiring caching of the coordinate rotations, the
'R()' method can be used with multiple input points:

       tensorField rots(cs.R(somePoints));

   and later

       Foam::transformList(rots, someVectors);

The rotation() method can also be used to change the rotation tensor
via a new coordinateRotation definition (issue #879).

The new methods transformPoint/invTransformPoint provide
transformations with an origin offset using Cartesian for both local
and global points. These can be used to determine the local position
based on the origin/rotation without interpreting it as a r-theta-z
value, for example.

================
  Input format
================

- Streamline dictionary input requirements

  * The default type is cartesian.
  * The default rotation type is the commonly used axes rotation
    specification (with e1/e2/3), which is assumed if the 'rotation'
    sub-dictionary does not exist.

    Example,

    Compact specification:

        coordinateSystem
        {
            origin  (0 0 0);
            e2      (0 1 0);
            e3      (0.5 0 0.866025);
        }

    Full specification (also accepts the longer 'coordinateRotation'
    sub-dictionary name):

        coordinateSystem
        {
            type    cartesian;
            origin  (0 0 0);

            rotation
            {
                type    axes;
                e2      (0 1 0);
                e3      (0.5 0 0.866025);
            }
        }

   This simplifies the input for many cases.

- Additional rotation specification 'none' (an identity rotation):

      coordinateSystem
      {
          origin  (0 0 0);
          rotation { type none; }
      }

- Additional rotation specification 'axisAngle', which is similar
  to the -rotate-angle option for transforming points (issue #660).
  For some cases this can be more intuitive.

  For example,

      rotation
      {
          type    axisAngle;
          axis    (0 1 0);
          angle   30;
      }
  vs.
      rotation
      {
          type    axes;
          e2      (0 1 0);
          e3      (0.5 0 0.866025);
      }

- shorter names (or older longer names) for the coordinate rotation
  specification.

     euler         EulerRotation
     starcd        STARCDRotation
     axes          axesRotation

================
  Coding Style
================
- use Foam::coordSystem namespace for categories of coordinate systems
  (cartesian, cylindrical, indirect). This reduces potential name
  clashes and makes a clearer declaration. Eg,

      coordSystem::cartesian csys_;

  The older names (eg, cartesianCS, etc) remain available via typedefs.

- added coordinateRotations namespace for better organization and
  reduce potential name clashes.

- for installations with central (non-ThirdParty) location for KAHIP
  (eg, spack, EasyBuild)

- avoids compiler ambiguity when virtual methods such as
  IOdictionary::read() exist.

- the method was introduced in 1806, and was thus not yet widely used

- ignore implicit-fallthrough for ragel generated code.

- add -Wno-deprecated-declarations for c++LESSWARN.
  These principally associated with older CGAL versions and their use
  of particular mpfr routines.

- since 1612, FOAM_INST_DIR and foamInstDir longer have any
  special meanings when sourcing the bashrc or cshrc files.
  Thus no need for special treatment in any of the dispatch wrappers.

  Retained FOAM_INST_DIR as (unexported) variable in etc/bashrc,
  just in case people are using patched versions of etc/bashrc
  as part of their installation.

ENH: relax prefix restrictions on foamCreateVideo (issue #904)

- shift the implicit '.' to be part of the default prefix. This allows
  things like "-image myimages_00" to work as might be expected.

- this is consistent with compiler defaults, and helps Darwin users

- tie the MPI rules to the base compiler type *without* its version.
  Eg, linux64Gcc (which exists) instead of linux64Gcc81

- downgrades some diagnostics about nonconformant code from errors to
  warnings. Oddly enough, the errors actually arise from STL library
  elements shipped with gcc itself. Affects kahip compilation with
  gcc-6, gcc-7

- required if there is no system openmp and libomp or libgomp are
  only found in the clang hierarchy

STYLE: add some notes in the openmp rules.

- the _OPENMP macro is now used in low-level testing files

- allows enabling new warnings without causing messy output with older
  clang versions

- improvement documentation for surface sampling.

- can now specify alternative sampling scheme for obtaining the
  face values instead of just using the "cell" value. For example,

      sampleScheme    cellPoint;

  This can be useful for cases when the surface is close to a boundary
  cell and there are large gradients in the sampled field.

- distanceSurface now handles non-closed surfaces more robustly.
  Unknown regions (not inside or outside) are marked internally and
  excluded from consideration. This allows use of 'signed' surfaces
  where not previously possible.

- since PackedBoolList is now a compatibility typedef for bitSet,
  it is useful to have an additional means of distinction.

STYLE: simplify internal version tests and compiler defines.

- the API version is now conveyed via the OPENFOAM define directly.
  The older OPENFOAM_PLUS define is provided for existing code.

- parsing error state only arises from a missing final newline
  in the file (which the dnl macro does not capture).
  Report with a warning instead of modifying the dnl macro since
  we generally wish to know about this anyhow.

- add missing newline to YEqn.H file.

- handling of dead links (find -L -delete unsupported)

- remove ignore case flag on 's/../../i' used in have_scotch script.
  It is unneeded and not tolerated by Darwin's sed.

- avoid embedded comments in EXE_INC (Make/options files), which do
  not work well with the OSX LLVM cpp.
  It strips out the comments but also removes the continuation char.

STYLE: adjust notes about paraview library locations

- was somewhat redundant in wmake/rules/General/general anyhow

- generalize some of the library extensions (.so vs .dylib).
  Provide as wmake 'sysFunctions'

- added note about unsupported/incomplete system support

- centralize detection of ThirdParty packages into wmake/ subdirectory
  by providing a series of scripts in the spirit of GNU autoconfig.
  For example,

      have_boost, have_readline, have_scotch, ...

  Each of the `have_<package>` scripts will generally provide the
  following type of functions:

      have_<package>          # detection
      no_<package>            # reset
      echo_<package>          # echoing

  and the following type of variables:

      HAVE_<package>          # unset or 'true'
      <package>_ARCH_PATH     # root for <package>
      <package>_INC_DIR       # include directory for <package>
      <package>_LIB_DIR       # library directory for <package>

  This simplifies the calling scripts:

      if have_metis
      then
          wmake metisDecomp
      fi

  As well as reducing clutter in the corresponding Make/options:

      EXE_INC = \
          -I$(METIS_INC_DIR) \
          -I../decompositionMethods/lnInclude

      LIB_LIBS = \
          -L$(METIS_LIB_DIR) -lmetis

  Any additional modifications (platform-specific or for an external build
  system) can now be made centrally.

- permits platform-specific override of the general CGAL rules

- the previous grammar used

      '/*' { fgoto comment; }

  to start processing multi-line comments and

      comment := any* :>> '*/' @{ fgoto main; };

  as a finishing action to return to normal lexing, but seemed not to
  have been triggered properly.

  Now simply trap in a single rule:

      '/*' any* :>> '*/';             # Multi-line comment

STYLE: use more compact dnl (delete to newline)

  OLD:   [^\n]* '\n'
  NEW:   (any* -- '\n') '\n'

  eliminates the intermediate state

- adjusted grammar to be more precise