Add archive utility

[hagertnl]

Adds the archive utility.

"Archive" does not interface with tape storage archives, but rather refers to a simplified test directory structure that optionally includes/excludes build directory and work directories. From that directory, you may tar/xfer/hsi_xfer those results anywhere, this script is just making that directory structure more amenable to archiving.

[hagertnl]

I tested this briefly this morning on some unit tests (testing a few runs of a failed check, failed build, and a successful test). This is now working, and I've confirmed that the deletion flags are operating correctly. As of now, I'm not aware of any bugs in this script. I do still need to update the docs before merging this, but the main thing that needs review is the utility itself.

Caveats -- the script does not filter out runs that haven't completed. All runs found in the time frame will be archived. If you have deletion flags like --delete-scratch-dir or --delete-run-dir, your actively running tests will fail. You should put a safe --endtime on the query. Running any of these delete options should be handled with extreme caution, as these are the only destructive flags available. I also do not endorse the use of --force, but it works, and it's there. I would strongly recommend handling single conflicting job IDs by hand.

[hagertnl]

One thing that's still under consideration is -- should we create a dot file like Run_Archive/<testid>/.archive_log.txt, where we append lines like:

Date                 Options                                    Path
2025-03-03T10:00:00  --keep-build-dir=ALWAYS                    /path/to/my/archive

[hagertnl]

As much as a .archive_log.txt might be nice, I think it may be best to pass on it for now. It's possible someone may want to archive tests as one user tests run by another user, and while we could add try/catch to say ".archive_log.txt can't be opened", I think it would be confusing when that file is there sometimes, but not there another. Given that archiving isn't destructive to the original directory by default, I'd say it's fine to continue without this log file.