Write 1D-compatible topo.data and dtopo.data for 1D runs

[mandli]

Adds code to handle 1D versions of topo.data and dtopo.data. Note that the choice to not have the 1D code support the more complex 2D capabilities and therefore input formats was deliberate. If there should be more parity this PR should be changed to reflect that.

[mandli]

PR Detailed Description -- Summarized by Claude

Companion: clawpack/clawutil#208, which passes num_dim in. Merge this
first — it defaults to num_dim=2, so it is inert and harmless on its own,
whereas clawutil landing first against an older geoclaw would break every
geoclaw setrun. #208 guards that case anyway, but the ordering makes the guard
unnecessary.

What was broken

Every one of the six examples/1d_classic cases aborted at startup:

Reading data file: topo.data
At line 58 of file .../src/1d_classic/shallow/topo_module.f90 (unit = 7, file = 'topo.data')
Fortran runtime error: Bad logical value while reading item 1

1D and 2D share TopographyData/DTopoData — ClawRunData builds the same
objects for both — but not the Fortran readers, and src/1d_classic was never
updated when #726 changed the file layouts. Line 58 is
read(iunit,*) override_topo_order, a logical: #726 dropped that line and
inserted the per-file preprocessing block, so 1D read a path string where it
expected T/F.

Fixing topo.data alone got five of six running. okada_dtopo then failed
further along:

At line 218 of file .../1d_classic/shallow/topo_module.f90 (unit = 7, file = 'dtopo.data')
Fortran runtime error: Bad integer for item 2 in list input

so dtopo.data needed the same treatment.

The two layouts are not symmetric

Worth spelling out, because the obvious symmetric fix is wrong in one direction
and unnecessary in the other.

read_topo_settings reads the path as a single list-directed item, so the
read is satisfied before it reaches any trailing comment. The topo path line
therefore keeps its # topo_path comment and works.

read_dtopo_settings reads two items in one statement:

read(iunit,*) dtopofname, dtopotype

List-directed input spans records, so the type sitting on the next line is
fine — that is why the pre-#726 format worked. What breaks it is the
# dtopo_path comment #726 added to the path line, which is consumed as
item 2. Hence the dtopo path line is written bare while the topo one is not.

There is a quieter consequence too. Had that read not aborted, the next
statement reads dt_max_dtopo, which would have landed on the preprocessing
block's crop_extent line and silently taken 0.0.

The change

TopographyData and DTopoData take num_dim (default 2, so 2D behaviour
and every existing direct construction are untouched) and write() branches on
it:

	1D	2D
topo.data	override_order line restored; path + type only	unchanged 10-line block
dtopo.data	bare path line; no preprocessing block	unchanged
NetCDF descriptor	omitted	unchanged

Preprocessing attributes set on a 1D file now emit a UserWarning naming them
and pointing at topotools, rather than being dropped silently — the
deliberate non-parity in the description is a real decision, but a user who
sets coarsen in 1D should be told it will not happen.

Verification

check	result
all six examples/1d_classic build and run	pass
same, with the fix reverted	Bad logical value while reading item 1, line 58 — the reported failure reproduced exactly
4 new unit tests in tests/test_data.py	pass; all 4 fail without the fix
pytest tests/ -m "not remote"	519 passed, 4 skipped, 1 xfailed
examples/tsunami/chile2010 (2D, has a dtopo)	6 passed

The new tests pin both layouts directly — line counts, the override_order
line, the bare dtopo path line, absence of the preprocessing block — plus one
asserting the 2D layout is unchanged and that num_dim still defaults to 2.
That last one is the guard against a future edit quietly making 1D the default
shape.

Note for anyone re-running the examples: several 1d_classic cases need
python make_celledges.py (and make_dtopo.py for okada_dtopo) before
make .output, and a stale .data timestamp file will hide a regenerated
layout. Neither is related to this change.

[rjleveque]

Thanks @mandli, this seems to work fine along with clawpack/clawutil#208