Add 1D version of GeoClaw solver

[ketch]

This is something I put together several years ago by straightforward modification of the 2D Geoclaw solver. I've been using it ever since but somehow never added it to the main repository.

I think @rjleveque has also been developing a 1D version of the Geoclaw solver that might be superior to this one but I don't know the status of that.

[mandli]

If this is updated to match the newest versions of the GeoClaw 2D solvers I would almost favor updating what's in geoclaw_riemann_utils.f as well. We have been meaning to update those and possibly update them to be faster but have not gotten around to it. This at least would make it in F90.

[rjleveque]

The 1D solver I was working on has been incorporated into GeoClaw (as of v5.10.0), see https://www.clawpack.org/geoclaw1d.html for documentation. There's no AMR but mapped grids are supported, which is very useful to go from large cells offshore to small cells onshore for realistic topo.

Note that a Boussinesq version is also available, https://www.clawpack.org/bouss1d.html.

There are some examples using both codes in
$CLAW/geoclaw/examples/1d_classic, shown in the gallery here. More examples would be good at some point.

These use the Riemann solver in $CLAW/geoclaw/examples/1d_classic/rp1_geoclaw.f90 and I realize now I should have put this in the riemann repository. It uses riemann_aug_JCP from $CLAW/riemann/src/geoclaw_riemann_utils.f.

@ketch, I'll talk a look at how your version compares to what I've been using. I think one or the other (or some combination) should be put in the riemann repository, but let's take a closer look before merging this.

I agree with @mandli that at some point we need to clean up these solvers, and I've also been talking with @dlgeorge recently about this in relation to the D-Claw solvers, which are similar but were branched off from GeoClaw at some point and so some things aren't identical that should be.

[ketch]

I recall that I had to make some major structural changes in order to get f2py to produce something that could be called from Python. So it may be necessary to have two versions (we already do for the 2D solver I think). Unless somebody knows a better solution.

[mandli]

I only recall there being an issue with common blocks, was there something in addition to that?

[ketch]

We have common blocks in a lot of solvers and those work fine with f2py. But it's been 10 years since I looked at this stuff so I don't recall what the issues are.