Added generator functions to FieldFactory

Take a user-supplied value, and return a FieldGenerator
object. Can be used to extend the FieldFactory class by
adding additional symbols.
Changes to FieldFactory

1. Put lexer information (current token etc.) into a private structure
   This allows FieldFactory::parse to be called recursively

2. Parse takes an Options pointer, which is used to find
   any unresolved symbols. This allows expressions to be broken into pieces

   -> The scoping rules, options sections etc. need to be worked out.

3. FieldFactory::parse caches the results, to speed up evaluation of functions,
   or where expressions are used in multiple places.

4. To handle deletion of FieldGenerator objects, each is added to
   a list as it is created. When FieldFactory is deleted,
   all the FieldGenerator objects it created are also deleted.
Added "power" function to FieldFactory

Power(x,y) performs exponent x^y. Added for
compatibility with Mathematica scripts
Refactoring of FieldFactory

Trying to separate BOUT++ specific part, from back-end parser.
Aim is to be able to test the parser without Mesh, Fields etc.
FieldFactory: Changed generator interface

FieldGenerator::generate now takes 4 doubles as input:

(double x, double y, double z, double t)

and no pointer to a Mesh. This means:

o The parser (ExpressionParser) is decoupled from other BOUT++
  objects e.g. Mesh, Field, Output, Options
  and so can be unit tested in isolation (or used in other projects)

o For now Field2D and Field3D objects can't be turned into generators
  (since indices not given). This should be possible though using interpolation

o The generator is intended for continuous expressions. Could this
  be used to automatically differentiate expressions numerically?
FieldFactory: variable scope working

Variables without a section (e.g.  "a", "nx") are looked
for in the current section, then all parent sections.

Variables with sections (e.g. "mesh:nx") start from root section,
and look only in Options->getRoot()->getSection(mesh), and not its parents (for now).

May need refinement, depending on use cases, and what people find
most intuitive.
Adding FieldFactory singleton

Not sure if this is the right way to go, as I have
tried to avoid adding more singletons aka global variables.
Nevertheless, it seems like the most practical way forward
for now... what could possibly go wrong?
FieldFactory::create*D improvements

o Can create fields at a given cell location
o Can specify a time to be passed to the generators
Adding mms flag to Solver
Merging FieldFactory improvements

Should enable more of the MMS functions to be specified in the input
file, rather than as additional functions