Both u and a were written to and read from the field 'u'

- The configuration parameter io.writeVTK is now io.vtk.write
- The configuration parameters restarts.first and restarts.spacing
  were moved into the io namespace
- Restarts are stored in a separate file
- VTK data, restarts (in HDF5), and the other HDF5 data are now
  each controlled through a parameter:
    io.data.write, io.restarts.write, io.vtk.write

In particular, it is thus now possible to write VTK data while
opening the data and restart files in read-only mode (or not at all);
This makes it possible to, by keeping the restarts file (and the binary!)
around, quickly (re-)compute a a small segment from the history.

The likeliest scenario: VTK files are huge and for a computation with
tens of thousands of timesteps (e.g. 30000), we know already (from the
data, or just expect it) that an event occurred during the last 500
timesteps. So we recompute them from a restart in the following mode:

  -io.restarts.first 29500
  -io.restarts.write false
  -io.data.write false
  -io.vtk.write true

Note that care needs to be taken to use a number for io.restarts.first
which is compatible with the old io.restarts.spacing

If either signal is detected, we try to terminate gracefully. If we're
given enough time before a nastier signal like SIGKILL is sent, we'll
then be able to finish computing and writing out the current timestep.

If we do not take such precautions, chances are the HDF5 output will be
corrupted.