Merge foundation

Foundation code merged
- all compiles - was not all clean and needed to resolve many conflicts
- updated InfoIn, WarningIn, ErrorIn messaging
- removed fluxRequired from tutorials
- currently testing tutorials

See merge request !25

ENH: Updated lagrangian libraries from internal development line



See merge request !22

Merge branch 'merge-foundation' of develop.openfoam.com:Development/OpenFOAM-dev-OpenCFD into merge-foundation

Adding optional files to smallPoolFire2D to run using this model.
Taking out of the compilation of FSD combustion. It needs futher work to run using the new turbulent framework

ENH: functionObjects: call execute on last time step

- old convention was that on last time step it would only call end()
and not execute()
- however this meant that e.g. the functionObjectProperties file
did not get written
- and almost all functionObjects were doing an execute() inside of end()
- new convention: call execute() on last time step, just before doing end()

See merge request !24

This was causing same event number on both U and grad(U) which meant
that if one of the processors had different event number the trigger
of gradient caching would not be synchronised. Now instead the overflow
is detected in the regIOobject::upToDate function and handled consistently
(by assuming that the events of object will never differ by more than
labelMax/2)

- old convention was that on last time step it would only call end()
and not execute()
- however this meant that e.g. the functionObjectProperties file
did not get written
- and almost all functionObjects were doing an execute() inside of end()
- new convention: call execute() on last time step, just before doing end()

Conflicts:
	src/OpenFOAM/db/regIOobject/regIOobject.C

Feature utils

Updated utilities bases on our internal development line

Still to do:
- update ParaView module builds to build alongside standard OpenFOAM code in separate directory

See merge request !21

fvOptions are transferred to the database on construction using
fv::options::New which returns a reference.  The same function can be
use for construction and lookup so that fvOptions are now entirely
demand-driven.

The abstract base-classes for fvOptions now reside in the finiteVolume
library simplifying compilation and linkage.  The concrete
implementations of fvOptions are still in the single monolithic
fvOptions library but in the future this will be separated into smaller
libraries based on application area which may be linked at run-time in
the same manner as functionObjects.

Corrects feature-request http://www.openfoam.org/mantisbt/view.php?id=1856
Patch provided by Juho Peltola