Extend inspect_commit.py to deal with non-csv files

[miridonoso]

Convert the non-csv files, like xlsx, to csv files and compare the diff between the csv files

• when comparing xlsx files with git diff, it does not compare the text because the file is compressed into a ZIP archive
• converting the files to csv would avoid this problem and avoid repeated code

An example of this is in hafsteinn/faroese_sentiment_analysis with hf_dataset.xlsx

[khatchad]

Reopened: this was closed automatically when #59 merged, not deliberately. The PR body carried the sentence "this does not close #43", and GitHub's closing-keyword parser reads "close #43" without the negation. Nothing in #59 addressed the foreign formats this issue is about; it widened reading to CSV, TSV and TAB, each optionally gzipped, which are formats the tool already knew how to parse. Converting xlsx and the other archive-backed formats is still open and still unstarted.

[khatchad]

On the blocked-by edge just recorded against #84: it is an ordering preference, not a prerequisite, and it should not stop anyone who wants to start here.

The reason for the edge is that this issue widens which files get opened, and a newly supported format still has to be reachable by name. Git hands over a path holding non-ASCII bytes escaped unless told otherwise, which is what #84 is about, so xlsx support landed first would carry the same blind spot CSV has today: an xlsx under a non-ASCII directory goes unread for a reason that has nothing to do with its format.

That is a reason to prefer an order, not a reason to wait. Nothing here needs the path handling in order to be implemented or reviewed. If #84 stalls, starting this is a defensible override rather than a violation of the metadata, and the cost of overriding is bounded: non-ASCII directories stay invisible to whatever formats get added until the path handling lands, which is one commit in the currently archived set.

The other blocker, #60, is the substantive one. It decides which format this issue should take on first, and that question is genuinely upstream of any work here.