Updating data points and data projections

Add functionality for each group of data points to be projected onto more than one mesh.
Change data point call by user number instead of global number

Tracker item 2000
Merge branch 'master' of https://github.com/OpenCMISS/cm

Conflicts:
	src/opencmiss.f90
Updating data projection routines

Change the way data projections are created within data points
Change the storage structure of projection results

Tracker item 2000
Data point based interpolation
Merge remote-tracking branch 'TimSzuHsienWu/master' into dataPointBasedInterpolation

Conflicts:
	src/interface_routines.f90
	src/types.f90
data point based interpolation save
Adding data_point_based_interpolation

Setting boundary condition on data point based interpolated field is not in this commit yet.

Tracker item: 3194
Merge branch 'master' of https://github.com/OpenCMISS/cm into dataPointBasedInterpolation
Data point based interpolation

Mainly for interface Lagrange variable

Tracker item: 3194
Merge branch 'master' of https://github.com/OpenCMISS/cm into dataPointBasedInterpolation

Conflicts:
	src/data_point_routines.f90
	src/field_routines.f90
Use NumPy arrays in the Python bindings

Replace the SWIG array typemaps with ones from NumPy's numpy.i file.
This has been modified to support output of 2D Fortran arrays and to use
a tuple for output of multiple parameters.
Input arrays are also now declared as const.
In order to work with the the NumPy typemaps, the C bindings have been
changed so that arrays of a known size, eg. see
"CMISSAnalyticAnalysisRmsErrorGetNode" for example use the square
bracket array syntax rather than pointer syntax.

This change requires NumPy when using the OpenCMISS Python bindings and
the NumPy header files in order to compile the Python bindings.

This will allow us to provide a "view" on data that has been allocated
within the library, eg. CMISSField_ParameterSetDataGet can be supported,
although this hasn't been implemented yet.

Tracker item 2147.
Support output of pointers to arrays in Python

- This allows Python to access data allocated internally by OpenCMISS, for
  example in CMISSField_ParameterSetDataGet.
- Pointers to arrays with intent INOUT are not yet supported, eg. for
  CMISSField_ParameterSetDataRestore. This will require having input and
  output sizes in the C bindings.
- I had to fix the intent for the CMISSField_ParameterSetDataGet and
  CMISSField_ParameterSetDataRestore routines as these were wrong.
- I also did some small reorganising when setting SWIG typemaps to remove
  some "if, elif, elif..." statements.

Tracker item 2147
Fix matrix ordering in Python bindings with NumPy

- Setting the Fortran flag doesn't seem to work as expected, I have to
  create the array with Fortran ordering from the start.
- There was also an error in the original numpy.i file with IN_FARRAY2
  when the size parameters are first. to_array_contiguous was used
  rather than to_array_fortran, and it appears that require_fortran
  doesn't actually work?
- Accidentally had added the APPEND_TO_RESULT macro twice so I've
  deleted one copy.

Tracker item 2147.
Support pointer arguments with intent INOUT from C

Tracker item 2147.
Support array pointers with intent INOUT in Python

Added a SWIG typemap for 1D array parameters passed by pointer with
intent INOUT. Required for CMISSField_ParameterSetDataRestore.
These require a NumPy array as an input with the correct
data type and dimensions. The array data pointer and size are modified
on output.

Tracker item 2147.
Add redirection for Python field routines

Allow calling the generic interface method when there are different
methods for different data types, eg. Field.ComponentValuesInitialise
can be called and will check the field variable data type, then call
ComponentValuesInitialiseDP or ComponentValuesInitialiseIntg etc.

Unfortunately I don't think it's possible to automate this in a general
way as we want to choose the routine based on the actual field data
type, not the type of input parameter. For example, if we have a field
with DP data type and we call the initialise routine with an integer
from Python, we still want it to call the InitialiseDP routine and cast
the Python integer to a double.

This means that this file will have to be manually updated as required.

Tracker item 2147.
Tidying up commit code
Add public distributed matrix/vector routines

These allow people to get access to matrix and vector data. For sparse
matrices the row and column indices can also be obtained.
Add routines for obtaining solver/equations matrices and vectors
Add method to create a SciPy sparse matrix from a distributed matrix

This will also reshape matrix data for full matrices (from 1D matrix
data to a 2D matrix).

Tracker item 2147
Fix getting sparse matrix data from PETSc

- Fixed MatGetArrayF90 in cmiss_petsc.f90 to use a 2D array argument.

- In distributed_matrix_data_get, cast the result to a 1D array with the
  correct dimensions.

PETSc's Fortran bindings have an error where they return a 2D array even
for sparse matrices from MatGetArrayF90. This meant that when treating
this as a 1D array we only got the first m non-zero values and when
using the C and Python bindings we got a segfault when using C_LOC.

There was some discussion about this on the PETSc mailing list but
nothing was done about it, leaving no way to properly get the matrix
data for a sparse matrix from Fortran:
http://lists.mcs.anl.gov/pipermail/petsc-users/2009-June/004682.html
http://lists.mcs.anl.gov/pipermail/petsc-users/2009-July/004687.html