update mod's "date modified" metadata when they are enabled and disabled

[ranenvious]

• [ X] I searched the issue tracker for other issues covering my case.

Is your feature request related to a problem? Please describe. Whenever I'm trying to make a large custom modpack I often enable, add, disable, etc. a few mods at a time since if I launched the game and fully tested the game every single time I changed any mod it would take hours to get even a handful of mods added. However, since enabling and disabling mods doesn't actually reflect itself on a file system level in any way, I have no real way of telling what I may have changed if the game starts to break or behave differently. While you could (rightfully) argue I should keep better track of that myself, the reality is that mods can break in unexpected ways and disabling (or enabling) a mod that you didn't think would matter may cause a serious breakage and, if you didn't think it would matter, you'd have no reason to remember doing it.

Just recently dynamic surroundings of all things ended up being the mod which made me unable to get to the title screen. I love dynamic surroundings as a mod, but it was mentioned no-where in the logs as the cause of the crash and I still don't know why it was causing a crash so early in loading that it stopped me from getting to the title screen. Identifying this issue took several hours because I quite simply never even considered that dynamic surroundings was the actual culprit, so when I thought I found the culprit I absentmindedly re-enabled dynamic surrounds without thinking about it, after all, why would a mod like dynamic surroundings be causing a crash like the one I was experiencing? (again, not trying to shit on DS here, I do love the mod and I understand that sometimes mods just be how they be and do how they do. Still though, it would have taken a lot less time to figure out the issue if I was able to look into my mods folder and see "oh, yeah, I did" re-enable dynamic surroundings a few minutes ago didn't I? let me try turning that back off and going back to the last state that I know was bootable!")

Describe the solution you'd like I think that, upon enabling or disabling a mod file, GDLauncher should update the "date modified" metadata of the file in question to reflect that change, even though technically the file itself wasn't modified and all that happened was ".disabled" was either appended to or removed from it's name.

Describe alternatives you've considered Another way to similarly help people keep track of any recent changes they've made to their pack might be to have an internal record of changes and modifications within GDlauncher itself and allow users to sort through that. However this would be much more complicated to implement and I don't personally see any way in which it would be superiour. It might be a bit easier for new users to grasp, however this use-case is niche enough that I don't think being extremely newbie friendly is enough of a concern to warrant the time spent implementing the feature within GDLauncher itself. (especially since if you ARE debugging a modpack, you're already going to have a file explorer open within the instance anyway to read the logs and such)

Additional context While I'm sure it's probably a bit of a programming faux pas to mess with file metadata in a manner it isn't intended (which this would classify as since it would be updating the "date modified" metadata without actually having modified the file, only changed it's name) given that the .jar files that would be affected are unlikely to be used by the user directly or programs outside of GDLauncher I don't think there is a significant risk in lightly manipulating the meta-data to make modpack creation slightly easier. The date modified field is supposed to help users sort files by when they were last modified, while changing the title of the file may not technically fit within that classification, in terms of use-cases it's basically the same.