Better project/setup_model interface for users

[rwilson]

We need to think about refactoring the code users change to run ANUGA. This is files like project.py, setup_model.py, etc.

Currently the code to put ASC elevations into ANUGA looks like:
convert_dem_from_ascii2netcdf(project.demname, ...)
dem2pts(project.demname, ...)
domain = create_domain_...(...)
domain.set_quantity('elevation', project.demname+'.pts', ...)

Hidden away under all that is the assumption that the filename passed to dem2pts() is just a root and '.dem' is *assumed* as the extension. This leads to confusion as:

1. project.demname is used all over as a root filename, no real names used,
   
2. sometimes extensions are supplied to a function with the filename, sometimes not.

We should always pass full filenames into functions. If there is an output file, the name for that should be supplied also. This will remove some confusion for beginners as to what is happening.

Additionally, it may now be possible to get ANUGA code to *automatically* convert files. If we say that a file is an "input elevation" file, then ANUGA can convert an ASC file to a PTS file just by looking at the extension (not a real good idea, but simple) or by some 'file'-like magic (do 'man file').

Similarly, a consistent function naming convention would be nice. In runcairns.py we see this to convert an ASC file to a DEM file:
convert_dem_from_ascii2netcdf(project.demname, ...)
dem2pts(project.demname, ...)

This could look like:
asc2dem(project.demname, ...)
dem2pts(project.demname, ...)

or
convert_asc_to_dem(project.demname, ...)
convert_dem_to_pts(project.demname, ...)

I general, a rethink on the 'user' code more from the aspect of 'a user just trying to run ANUGA' instead of an 'ANUGA developer' is called for.

[James Hudson]

Fixed in rev:7814. File extensions are enforced, and naming conventions for functions is consistent.