stagefiles: add default filename configuration mechanism

@hertzog

a few days ago with the last big chunk of stagefile work that was merged, there was one piece of the final solution which i adjusted per your request such that it could get merged, but i said that i'd split out the final aspect not agreed upon into a separate MR along with my response to the review comments you left about it, which i'm finally getting around to here.

by all means if you still feel the same after this, then just close this. it's a small thing i can live without :p

so, your primary points against it if i recall correctly were

1. visibility, with the var being initialised with the script's stagefile name "dozens" of lines before it's used.
2. the reliance upon the environment.

hopefully the relevant parts of the change being extracted into this small patch will help clarify what is going on if anything was lost in the size of the previous changeset.

in response to the first point:

1. the initialisation was located where it was because it needed to be located prior to the case statements in which it is used multiple times, so logically it was as close as it could be. the only way to bring it closer would be to defined it in each case branch of course.
2. the setting of the var is an entirely separate matter to the calling of the check/create functions; as i see it, setting the var is a configuration step, setting up the backend stagefile mechanism with the right filename so that whenever the stagefile API is later used through the remainder of the script, the right file (the script's own) is used. i've made this more clear in the tweaked solution submitted here whereby this configuration takes place through a function call rather than setting a variable. of course most other usage of the API does not involve the variable, because the variable is only involved where a few scripts need to do something abnormal.

in response to the second point:

1. i've added an unset line into stagefiles.sh which helps block external interference.
2. i'd agree that relying upon a global is not ideal since a problem occurs should any other code in the script ever try to make use of the STAGE_FILE variable name, but this is surely very unlikely, and there are negatives to passing the value along explicitly as a param also, as i previously pointed out - the vast majorityof scripts do not use a param, and the functions work with a default if no param is given (as opposed to giving a missing param error), and so with themodelof passing a param as we currently do, a bug could easily arise and go unnoticed later if a stagefile API function were ever called in one of these few scripts without the necessary param, whereas in this model of having a configuration step towards the beginning of the script setting the filename to use would prevent any such problem.

anyway, i leave it in your hands to merge or close.