fiberassign tertiary: which recorded path in header for TOO?

I m trying to make a decision for the design of the tertiary tiles.
posting that here, to have feedback/suggestions (e.g. @schlafly , @moustakas )
and also so that things are documented.

**context:**
- for those tertiary tiles, I "hack" the ToO channel, i.e. the provided "ToO" file to `fba_launch` is a special target file with the tertiary program targets
- in this PR https://github.com/desihub/fiberassign/pull/437, I ve implemented a safety requirement that the ToO file provided to `fba_launch` is in `$DESI_SURVEYOPS`(unless a `--custom_too_development` argument is passed)
- we commit those files to the svn, here: https://desi.lbl.gov/trac/browser/data/surveyops/trunk/tertiary.

For those tertiary programs, the design process usually is like:
- generate `ToO-PROGNUM-FIRST_TILE.ecsv`
- generate `fiberassign-FIRST_TILE.fits.gz`
- then generate `ToO-PROGNUM-SCND_TILE.ecsv`, with reading assignment from `fiberassign-FIRST_TILE.fits.gz`
- then generate `fiberassign-SCND_TILE.fits.gz`
- and so on,

so I ve kind of cornered myself here, because I need to work from a local `$DESI_SURVEYOPS` checkout so that I can write files there.
my bad, when making the PR https://github.com/desihub/fiberassign/pull/437, I missed this interleaved case of `ToO*ecsv` file creation and fiberassign.
if no action is taken, it s my local checkout path which will be recorded in the fiberassign header.
it s not dramatic, but it s not great either.

I could think of the following workarounds:

**workaround 1:**
in the header reported paths, use `DESISVOP` (ie DESI_SURVEYOPS fitting the 8-character limit) as a replacement of the $DESI_SURVEYOPS path.
we currently have something like:
```
DESIROOT= '/global/cfs/cdirs/desi'
GFA = 'DESIROOT/target/catalogs/dr9/1.1.1/gfas'
MTL = 'DESIROOT/survey/ops/surveyops/trunk/mtl/main/dark'
TOO = 'DESIROOT/survey/users/raichoor/svn/surveyops/trunk/tertiary/...'
```
it would be replaced by:
```
DESIROOT= '/global/cfs/cdirs/desi'
DESISVOP= '/global/cfs/cdirs/desi/users/raichoor/svn/surveyops/trunk'
GFA = 'DESIROOT/target/catalogs/dr9/1.1.1/gfas'
MTL = 'DESISVOP/mtl/main/dark'
TOO = 'DESISVOP/tertiary/...'
```
- pros: it kind of achieves the goal, provided that one should/could ignore the actual `DESISVOP` keyword value and use the "real" `/global/cfs/cdirs/desi/survey/ops/surveyops/trunk/`.
- cons: caveat mentioned in the pros; and also, it would make the change for the main tiles.

**workaround 2:**
once files are generated, I could edit the `fiberassign-TILEID.fits.gz` header and the `fiberassign-TILEID.log` file, with replacing my local checkout path with the official `$DESI_SURVEYOPS` path.
I would add a function like `fiberassign.fba_tertiary_io.update_desisvop_path()`.
- pros: achieves the goal.
- cons: not super nice to _a posteriori_ edit files.

**workaround 3:**
run the fiberassign design with some special privileges which authorize me to write in the "official" `$DESI_SURVEYOPS` folder.
- pros: achieves the goal, no code change needed.
- cons: it may be not recommended to do something like that.

**remark:**
the workaround I found for the tertiary calibration program only worked because it s just one tile at a time, there; so I can generate the `ToO-PROGNUM-FIRST_TILE.ecsv` file, commit it to svn, wait for it to be picked up, then run `fba_launch`.
but I cannot do that when there are lots of tiles in a design.

Start by reviewing PR #437 and the fba_launch path-recording flow, including the mentioned fba_tertiary_io area and generated fiberassign FITS headers and logs. Compare the three proposed workarounds and confirm the desired recorded path; done means the chosen approach is documented and generated tertiary outputs no longer expose the local checkout path.

Written by the indexing model from the issue text.