Make Field more powerful

[dschwoerer]

Currently it is quite hard to use Field for anything.
It cannot be used to checkdata, copy a field, or iterate over it.
Therefore the solver e.g. needs to maintain a separate list for field3d and field2d - fieldperp or other fields are not supported.
This breaks the usefulness of the fields being derived from field.
Therefore fixing #208 is rather useless - as it would require much work or be of limited use.

checkData(Field) could be implemented to use RTTI to do the job - but that is not a nice solution - and would be trivially avoided if checkData() would be a member function of Field - then the vtable would resolve to the appropriate implementation of checkData at runtime.
Field3D shouldn't be (much) slower, if it is marked as final ...

To summarize:

• Do we want other Fields?
• Should we use RTTI or make fiend functions member functions?
• Is there a better way to make use use Field more often, rather then being limited to Field3D?

[bendudson]

Field and FieldData should be merged, in my opinion. It's hard to make much use of Field in any performance-critical parts of the code, due to the vtable indirection needed. Generally I think we can use polymorphism at compile time: checkData overloaded for different field types; polymorphism less commonly needed at runtime. There are some places which are not performance critical where it would be nice though.

[ZedThree]

I think this mostly done in #2313. as well as more use of templates.

There's still places where this could be improved (e.g. Solver's use of separate vectors for each field type), but we're getting there