allow topo override_order with dtopo files

[rjleveque]

I implemented the strategy suggested in #689 -- first rank ordering the original topo files and then inserting the topo_for_dtopo files in this list.

I've tested it with random collections of topo and dtopo files and I think the ordering is working as intended.

I also improved what is written out to the file _output/fort.geo to report on the ordering actually being used in the run. For example, a case with 5 topo files and 3 dtopo files (filenumbers # 6,7,8) gives this output when run with rundata.topo_data.override_order = False :

 Ranking of topography files  (including topo_for_dtopo) finest to coarsest: 
    (filenumber is order they appear in setrun.py, topofiles first)
  
rank =   1  filenumber =   5  dx*dy =     0.857339E-08
rank =   2  filenumber =   3  dx*dy =     0.857339E-08
rank =   3  filenumber =   6  dx*dy =     0.771605E-05
rank =   4  filenumber =   4  dx*dy =     0.694444E-04
rank =   5  filenumber =   2  dx*dy =     0.694444E-04
rank =   6  filenumber =   8  dx*dy =     0.256000E-03
rank =   7  filenumber =   1  dx*dy =     0.277778E-03
rank =   8  filenumber =   7  dx*dy =     0.102030E-01

and the following output when run with rundata.topo_data.override_order = True :

 Ranking of topography files  (including topo_for_dtopo) finest to coarsest: 
    (filenumber is order they appear in setrun.py, topofiles first)
  
rank =   1  filenumber =   5  dx*dy =     0.857339E-08
rank =   2  filenumber =   6  dx*dy =     0.771605E-05
rank =   3  filenumber =   4  dx*dy =     0.694444E-04
rank =   4  filenumber =   3  dx*dy =     0.857339E-08
rank =   5  filenumber =   2  dx*dy =     0.694444E-04
rank =   6  filenumber =   8  dx*dy =     0.256000E-03
rank =   7  filenumber =   1  dx*dy =     0.277778E-03
rank =   8  filenumber =   7  dx*dy =     0.102030E-01

[mandli]

Looks like this may be a way to go. Does the output in all the examples stay the same? We should really probably come up with a test/example that flexes the override_order functionality if we are going to keep it.

As an aside, it looks like the white space was all deleted. Need to remove that from the source generally, but makes it look like a lot more has changed.

[rjleveque]

@mandli: I haven't done a careful test, but none of our examples had multiple topo or dtopo files with nearly equal resolution and so I don't think this will change anything.

Sorry about the white space, I agree at some point when things are stable we should purge it all and then try to keep it that way.

[rjleveque]

I removed the white space changes so this PR is now cleaner, in case it has bugs. We can fix the white space later.

[rjleveque]

I think this is working well enough to merge, and I'll put a note in the release notes and in the documentation https://www.clawpack.org/topo_order.html to note that there is now a fudge factor included for files that are nearly equal resolution.