Change sediment field to being a standard scalar field

The schema currently has sediment as a separate element in a material phase. Within this element you are able to specify a sediment field template, a sediment deposition field, and any number of sediment classes that use the sediment field template with customisation of specific sediment related parameters.

This has the following benefits:
- It ensures that all of the sediment fields are on the same mesh
- Several parameters only need to be specified once, including:
     - discretisation and solver settings
     - boundary and initial conditions (where appropriate)
     - density, diameter, porosity, erodability and critical shear stress (if any of these are the same for many sediment fields)
- It ensures that a sediment deposition field is created by making this essential for an flml file to be valid when using sediment

However, it has the following disadvantages:
- It requires a complicated sediment initialisation routine that must be maintained.
- It complicates running from checkpoints for sediment problems. This is due to the fact that diamond sees a checkpoint flml file as having an invalid structure
- there may be other issues that arise from this complication if changes are made to how sediments work. For example, if there is an option for a sediment field with distributed grain sizes (although I'm sure there would be a way to fit this into the current configuration)

I am suggesting that the benefits of this set up relating to being able to edit all sediment fields with a single change, are not so important now that it is easy to slice and group similar properties in diamond, and also copy/paste elements.

I also suggest that ensuring that a sediment deposition field is specified could be done via an error from fluidity if it is not. This would make it the same as when using a free surface and a free-surface diagnostic field is required.

Ensuring all sediment is on the same mesh could also be done through checks when running fluidity - The schema can be defined to suggest a mesh choice i.e. VelocityMesh

I think it would make the schema tidier, and the code easier to maintain, if a sediment field was included in the list of available scalar fields, in the same way as any other scalar field.