FileInfo.source_path is evidence relative for three seekers and an absolute local path for two

`FileInfo.source_path` means two different things depending on which seeker produced it.

Three seekers store an evidence relative path:

- `FileSeekerZip` stores the archive member name (`scripts/search_files.py:933`)
- `FileSeekerTar` stores `member.name` (`scripts/search_files.py:826`)
- `FileSeekerItunes` stores the reconstructed relative path (`scripts/search_files.py:755`)

Two store the absolute path on the machine running the tool:

- `FileSeekerDir` stores `item` (`scripts/search_files.py:496`)
- `FileSeekerFile` stores `self.single_file_abs_path` (`scripts/search_files.py:1090`)

Measured on the same evidence, run once as a folder and once zipped, reading
`_file_path_list.file_path` back out of the LAVA database:

| input | stored value |
| --- | --- |
| `-t zip` | `data/media/0/Download/sample.torrent` |
| `-t fs` | `/Users///extraction/data/media/0/Download/sample.torrent` |

## Where the value travels

It does not stay in the seeker.

1. It is written into the LAVA database as `_file_path_list.file_path` (`ileapp.py:532`).
2. It is copied onto every media item as `media_item.source_path` (`scripts/ilapfuncs.py:276`),
which lavafuncs writes into LAVA (`scripts/lavafuncs.py:540`).
3. The media id is derived from it (`scripts/ilapfuncs.py:354`):

```python
media_id = hashlib.sha1(f"{file_info.source_path}".encode()).hexdigest()
```

## Consequences

- On a folder or single file extraction the report carries the examiner's home directory
and case folder into the LAVA database, both in `_file_path_list` and on media rows.
Archive input does not do this.
- Media ids are not stable across input types. The same evidence processed as a folder and
as a zip produces different media ids, because the id is a hash of a value that differs
between the two.
- A field that means one thing for three seekers and another for two is hard for anything
downstream to consume correctly.

## What needs deciding

Normalising `FileSeekerDir` and `FileSeekerFile` to store the evidence relative path would
make the field mean one thing and would keep local paths out of LAVA. It would also change
every media id on folder and single file extractions, because the id is a hash of that
value. That is the part worth discussing rather than simply changing:

- whether changing media ids on folder runs is acceptable, and what it affects on the LAVA side
- whether the media id should be keyed on something that does not move, such as the content
hash, rather than on a path
- whether any existing case needs to keep reproducing its current ids

This affects all five cores. Line numbers are from iLEAPP at
`81ad005f0c31237b3272196a856c01c9b3772f43`; the sibling cores carry the same shape at
different line numbers.

Raised while removing local paths from the processed files log. That change is separate and
does not touch any of this.