ENH: update handling of versioning and make control (issue #1010)

• 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

CONFIG: relocate WM_PROJECT_SITE default

• was /site, now /site

  This avoids several issues when installing OpenFOAM in clusters without an intermediate OpenFOAM-specific installation prefix.

  The 'site' directory may have a reserved meaning in these situations and it is undesirable to 'leak' upwards into the parent directory to look for configuration files.

  Placing the default within the project directory avoids this. Alternative locations can be given via the WM_PROJECT_SITE variable.

• removed foamExec, which was previously used when switching versions and before the bash/csh discovery logic was used

ENH: add csh support to foamConfigurePaths