Support reading gauges in binary format

[rjleveque]

This modifies pyclaw.gauges so that binary files are supported, as can be created with the geoclaw enhancement in clawpack/geoclaw#537.

This should be backward compatible for standard ascii output, and also should automatically find binary output if the new format is used -- The file gauge0000N.txt always contains the header, but if it has no data, we now look for gauge0000N.bin to read the binary data from.

[ketch]

This looks fine to me. It would be great to also add an example of a binary output file and a test, but then again we ought to already have a test for the ascii format.

Might be nice to allow file_format to be passed as a keyword argument, and only try to figure it out if that argument isn't passed.

[rjleveque]

Thanks @ketch! There is a new unit test in the GeoClaw PR, clawpack/geoclaw#537, and the Gauge 2 files from geoclaw/tests/dtopo1/regression_data could be copied over to make a simple unit test.

On the other hand it occurs to me now that the .bin file format may vary on other machines, so I should really change that example to read in the binary file that running the unit test created but then compare it to the data from the .txt file in regression_data. Since the ascii and binary gauges are in the same location, those should agree. For PyClaw it would be best to do something similar, only reading a binary file that was just created in the same unit test.

Regarding adding file_format as an argument to read, that's how I first implemented it, but then I realized it would be best to keep the .txt file too with the header, since that info is needed in order to reshape the data read in from the .bin file. So then I was happy to avoid the extra parameter, so the user doesn't have to worry about setting it properly.

It occurs to me this would also be good to do when reading time frames. We always write a fort.q file with the grid headers and then the data goes there too in the 'ascii' case, or into fort.b files in the 'binary' case. It would be easy to check if there are only headers in fort.q and if so look for fort.b files. This would avoid various problem we run into with specifying plotdata.format, e.g. clawpack/visclaw#275.

[ketch]

Sounds good. Regarding automated detection of regular output files, we would want to make sure that it takes into account all output formats (not just ascii and the standard binary).