feat: add extra extensions to text editor app

[tralph3]

Description

Adds more extensions to the file manager app. The previous selection was quite sparse, leaving out a lot of common files. These additions should make it more universal. In the future, maybe it'd be better to rely on a text detection method, rather than extensions.

Types of changes

• Bugfix
• Enhancement (a change that doesn't break existing code or deployments)
• Breaking change (a modification that affects current functionality)
• Technical debt (addressing code that needs refactoring or improvements)
• Tests (adding or improving tests)
• Documentation (updates or additions to documentation)
• Maintenance (like dependency updates or tooling adjustments)

[JammingBen]

Looks good, thanks!

I'm waiting for the merge because we're currently in a hardening sprint for the upcoming stable release and this is technically a feature. I'll merge it once we have a stable branch.

In the future, maybe it'd be better to rely on a text detection method, rather than extensions.

I agree. The issue is that we need to rely on information the server gives us in the PROPFIND. Any (potentially expensive) text detection wouldn't work. Still, there are better ways to do this than via the file extension.

[JammingBen]

Since we got a stable branch now, this can be merged. Could you please rebase it with current main before? We had a few CI-related changes in the meantime.

[tralph3]

There, I added some more extensions in the meantime.

But this really should be handled differently. What could be done is check the first 64k of the file and look for any non-printable chars. This should be treated as a UTF8 string of course. If none are found, we can pretty reasonably assume its a text file.

We can also have some tolerance by detecting a ratio of printable to non-printable, and if the ratio is high enough, we treat it as text anyway.

What I don't know is, how does the editor handle non-printable chars? Can it display them fine-ish? Or does it fail completely?