tsort: remove unnecessary uses of unsafe

[mrkalling]

The unsafe code was used to look up values in a hash table without checking whether the values were present. Verifying that a lookup succeeds only requires a few additional instructions, while avoiding unsafe makes the code easier to understand, analyze, and maintain.

If a lookup fails, the program now panics as such a failure indicates a programming error.

[github-actions]

GNU testsuite comparison:

Skipping an intermittent issue tests/date/date-locale-hour (passes in this run but fails in the 'main' branch)
Skipping an intermittent issue tests/date/resolution (passes in this run but fails in the 'main' branch)
Skipping an intermittent issue tests/pr/bounded-memory (passes in this run but fails in the 'main' branch)
Skipping an intermittent issue tests/tail/tail-n0f (passes in this run but fails in the 'main' branch)
Note: The gnu test tests/rm/many-dir-entries-vs-OOM is now being skipped but was previously passing.

[oech3]

We should deduplicate validations in the code base instead of duplicationg validation. I don't agree with simply removing unsafe which is logically safe.

[xtqqczze]

cc: @anastygnome (as author of #9872)

[mrkalling]

I would absolutely agree if these unsafe blocks had provided a substantial performance improvement. At best, the unsafe code improves performance by only 0.3%. As I see it, there is still a lot of potential for performance improvements in tsort, and it would be easier to achieve those improvements without using unsafe code.

I've attached my performance measurements, collected with Callgrind, for both the safe and unsafe implementations.

tsort prfomence.csv