The function object now computes the acoustic pressure at a list of user
specified locations, or from the face centres of a user-supplied surface.
When operating on an input surface, the output can be written back to the
surface or as a list of point values.

Example of function object specification:

    Curle1
    {
        type            Curle;
        libs            ("libfieldFunctionObjects.so");
        ...
        patches         (surface1 surface2);
        c0              330;

        // Input - either points or surface

        input           points;
        observerPositions ((0 0 0)(1 0 0));

        //input           surface;
        //surface         "inputSurface.obj"

        // Output - either points or surface
        output          points;

        //output          surface;
        //surfaceType     ensight;
    }

    Where the entries comprise:
        Property     | Description                  | Required | Default value
        type         |...

lumped point motion using local linear basic functions (#1341)

See merge request !271

- see its accompanying README for additional setup instructions

- the earlier implementation of externally controlled lumped point
  motion (see merge request !120 and OpenFOAM-v1706 release notes) was
  conceived for the motion of simple structures such as buildings or
  simple beams. The motion controller was simply defined in terms of
  an orientation axis and divisions along that axis.

  To include complex structures, multiple motion controllers are
  defined in terms of support points and connectivity.

  The points can have additional node Ids associated with them, which
  makes it easier to map to/from FEA models.

  OLD system/lumpedPointMovement specification
  --------------------------------------------

      //- Reference axis for the locations
      axis            (0 0 1);

      //- Locations of the lumped points
      locations       (0 0.05 .. 0.5);

  NEW system/lumpedPointMovement specification
  --------------------------------------------

      // Locations of the lumped points
      points
      (
          (0  0  0.00)
          (0  0  0.05)
          ...
          (0  0  0.50)
      );

      //- Connectivity for motion controllers
      controllers
      {
          vertical
          {
              pointLabels (0 1 2 3 4 5 6 7 8 9 10);
          }
      }

  And the controller(s) must be associated with the given
  pointDisplacement patch. Eg,

     somePatch
     {
         type            lumpedPointDisplacement;
         value           uniform (0 0 0);
         controllers     ( vertical );   // <-- NEW
     }

TUT: adjust building motion tutorial

- use new controllor definitions
- replace building response file with executable
- add updateControl in dynamicMeshDict for slowly moving structure

- use simpler decomposeParDict in tutorials, several had old
  'boilerplate' decomposeParDict

- use simpler libs () format

- update surface sampling to use dictionary format

COMP: provide modules/Allwmake script

- unified entry point with -prefix=... handling (#1721)

COMP: automatically add FlexLexer.h to MSwindows OSspecific

- useful, frequently forgotten step for cross-compiling

DOC-STYLE: various release changes

See merge request !370

- place under compressibleInterFoam to ensure that the library
  dependency on VoFphaseCompressibleTurbulenceModels is satisfied

- build prior to transportModels, which includes geometricVoF and its
  own form of surface sampling (interface sampling)

Updates for the adjoint optimisation library

See merge request !368

- Removed some unnecessary dynamicMeshDicts.
- Removed the writeActiveDesignVariables execution from the Allrun
  scripts, since it is no longer necessary to execute it before
  adjointOptimisationFoam.
- Updated the entries in dynamicMeshDict according to efbc9fc9.

(old keywords are still valid, throwing a compatibility warning)

- using (U,V,W) instead of (X1,X2,X3)
- using confine instead of bound

for all objective functions.

- The normalization is useful for practically all update methods dealing
with constraints (e.g. SQP, MMA). The normalization factor can be either
given explicitly or, if not given, will be the value of the objective
function in the first optimisation cycle.
- The target value is useful when using the objective as a constraint in
constrained optimisation problems (e.g. drag - dragTarget). It should
only be used with update methods that understand the value of the
constraint (e.g. SQP, MMA) but not when the objective in hand is the
only objective of the optimisation problem. In such a case, a squared
objective should be used (e.g. sqr(drag - dragTarget))

- Objective now inherits from localIOdictionary and writes the mean
objective value under the uniform folder, each time mesh.write() is
called. This is crucial for getting the correct old merit function value
if the simulation is continued from a previous state and lineSearch is
used.
- Objectives are now computed and written even if the corresponding
adjoint solver is inactive. This, among others, is also essential for
getting the correct old merit function value in case of continuation.
- Writing of the objective function (and its mean, if present) history
has now moved to updatePrimalBasedQuantities, instead of the preLoop
part of the adjoint solvers. This was decided to get the objective
values to files, even if the adjoint solver is inactive. Arguably, an
even better place to write the objective functions would be the postLoop
part of the primal solvers, however this might cause multiple writes of
the objective value for the inner iterations of lineSearch, if one is
used.

to be used in separating instantaneous objective values of different
optimisation cycles.

which qualitatively quantifies noise through a volume integral of the squared
turbulent viscosity.

Moved part common to all derived classes (e.g. update) to the base
class to avoid code duplication. Practically, only the protected
updateDesignVariables has to be overwritten in each derived class now.
steadyOptimisation was also affected in a minor way.

holding the sensitivity maps

given a global control point ID

without recomputing them. Use with caution!

- Added function returning the underlaying surface sensitivities
- Added boolean to control whether to write the underlaying sensitivity
  map (defaults to false)

Encapsulates all terms that are common in both E(SI) and FI
formulations, like direct sensitivities and sensitivities due to
primal boundary conditions. Added the latter to all derived sensitivity
types, except for sensitivity maps.

Same as adjointWallVelocity but also returns the contribution
of the differentiation of the rotatingWallVelocity BC wrt the
face centres, to be added to the sensitivity derivatives.

Main reason was the insertion of a templated virtual function
returning the contribution of the differentiation of the primal
boundary condition, in the case the latter directly depends on a
a geometric quantity (e.g. rotatingWallVelocity).

Example usage:

    removeParcels1
    {
        type            removeParcels;
        log             yes;
        resetOnWrite    no;
        resetOnStart    no;
        faceZones       (cycLeft cycRight);
    }

Number and mass of particles removed are written to file