save_restore request-file path

[Tim Mooney <mooney@aps.anl.gov>]

I have a solution that seems to work pretty well for telling save_restore where
all to look for autosave request files.  As I recall, the problems that needed
solving include the following:

1) Allow included request files to be located with the databases or
    records they represent.  In particular, allow each version of
    a support module to have its own request files, without requiring any
    modification to st.cmd, or to any autosave request files, to switch
    modules.

2) Allow, but don't require, request files to be installed with databases,
    e.g., in std/db.

3) Don't require calloc/strcpy/strcat in st.cmd to construct file paths.

4) Allow user easily to override included request files at any level of
    include.  (Practically, this means that request files should not specify
    path fragments for request files they include.)

The solution turned out to be trivial, so I'm wondering if I left something
out.  I just added the function

	add_requestfile_path(char *path, char *sub_path)

to save_restore.c.  All it does is concatenate its arguments (checks for '/',
etc.) and call set_requestfile_path().  With this, a st.cmd file might contain
the following save_restore setup:

	< cdCommands
	...
	# specify where request files come from
	set_requestfile_path('./')
	add_requestfile_path(std, 'stdApp/Db')
	add_requestfile_path(ip, 'ipApp/Db')
	add_requestfile_path(mca, 'mcaApp/Db')
	add_requestfile_path(motor, 'motorApp/Db')

This looks like, and the function names imply that, a call to
set_requestfile_path() should precede any calls to add_requestfile_path(),
but that's not actually the way it works.  The calls can occur in any order,
and you could just forget about set_requestfile_path() and say

	add_requestfile_path('./', '')

or (under vxWorks) even

	add_requestfile_path('./')

(Under vxWorks, I suppose I could have just added a second argument to 
set_requestfile_path(), but this surely wouldn't work for all operating
systems.)

As before, directories are searched in the order they were specified, and
the first match wins; it's up to the operating system to interpret
path names; and it's somebody else's job to mount the file system.

Anybody see problems with this?

Tim