This commit adds stack-structured timing code, such that bits of SPINS
can be instrumented with

>  timing_push("short name")
>  [... work goes here]
>  timing_pop()

This is recursive, such that already-timed portions of the code can call
the timing code to further instrument subroutines or discrete code
segments, and the resulting structure follows the -dynamic- call stack.
This does have the odd result that portions of the code that are re-used
(namely spectral derivatives) can show up as several 'leaf' nodes in the
graph.

To print out the report to standard error, call

>  timing_stack_report()

The exact format of the report should be considered tentative.

The rectangular-matrix solve inside the GMRES code is computed with the
LAPACK function DGELSD.  This function has a 'workspace query' in order
to give the proper allocation of the workspace array.  As it turns out,
the -integer- work array (as opposed to the floating-point one) is of a
fixed size, and it can be allocated ahead of time.  Not doing so caused
problems with MKL on SciNet, since even for the query the intel version
of LAPACK wrote to this array (causing a segmentation fault).

In a Valgrind check, several usages of uninitialized memory in the
multigrid code were being caught.  This was related to the check for
boundary-condition indefiniteness/validity at the coarsest level.  In
effect these errors were harmless, but fixing them will make future
Valgrind checks cleaner.

This is the initial commit of SPINS to a git repository, coming from
an essentially unmanaged environment.  While this is a *complete*
archive, this is probably not the most useful form for development
going forward.  Notably, the future management should be:

1) Pare down the case files

2) Establish branches for individual users.  Not as a long-term goal,
   but instead to keep user-specific case files from lingering in
   the main repository long after their use is obsolete.

2b) Establish semipermanent branches for typical users.  A release
   branch should include the basic documentation cases, a benchmark
   case should include benchmarking cases, and there are probably
   others that aren't coming to mind now.

3) Add helpful MATLAB processing scripts to the repository.  Too
   much of that is ad-hoc now, completely unmanaged.

4) For papers/etc, establish tagged versions.