Issue Description:

Ok, this is a pretty big request, but it will add tremendous power to CT users. Essentially I want to be able to read text files (only the ones found in the config folder for security reasons) and either retrieve the string containing all of the file or ideally, a specific value from the config file. For example :

getValFromCfg("examplemod.cfg","general.I:rfGeneration");

or something like that.

Honestly, this just isn't going to be safe, people may store passwords in the config folder (I believe reAuth stores files there, and I'm sure there are more).
Ontop of that, people store configs in different format and we can't support all of them.

Also config options can be changed after the game has loaded, which wouldn't be reflected in scripts, and even having this could cause desyncs in clients and servers.

First of all, it's much easier to install a mod than it is to add a script nowadays, so I wouldn't say it's less safe than any mod that can do the same thing and more and be accepted into curse in a matter of minutes. Btw, reauth doesn't save passwords in the config folder, it only did for the first few versions iirc. About the format, as I said, we should have the option to just retrieve the whole contents of the file, or, if the file uses forge config standards we can use the automatic methods (which people can also script themselves if you just add file reading) so you don't really need to worry about a hundred formats. Now for the last one, I don't really see an easy solution, I don't know exactly how crafttwaker works internally, but my general thought is that restricting something just because it 'can' cause desync is not the right way to go, many configs break if they are not the same with the client and the server. (I'm tired and also sick so please forgive me for typos or stupid logic )

File access is something we agreed CrT should not allow, because of multiple reasons:

• If we added CrT methods that allowed people to access one folder, some of them can and will find loopholes to expand that access to other folders as well.
• There would definitely be conflicts between different file systems, like UMF and NTFS, which we already had to deal within the realms of ZS alone, trying to add a custom syntax for that would be too much of an effort compared to the gain.
  Examples:
  • File Separator: / vs. \ would definitely pose an issue as ntfs uses backslashes.
  • Casing: UMF is case sensitive whereas NTFS is not. This would be an issue if people only test on windows
  • Different permission systems: If people who don't know much on UMF set up a linux server they might prohibit reading access to a file thus creating IOExceptions when reading them.
• File access typically is slow and bound to many exceptions. ZS is meant to be a fast and simple scripting language, we don't even support a try/catch system, which would be required, because otherwise people would have to deal with many null checks and the like.
• Retrieving the whole contents of a file is really memory exhausting and in most cases a bad practice, that's what readers/bufferedReaders are normally for. But they are a system that would be outside the scope of CrT.
• There are many cases when accessing a file incorrectly can lock that file for other applications. If, for example CrT reads that file, errors and doesn't close the reader correctly, it is very well possible that other mods that need to write to that file will be blocked from doing so thus causing strange issues or crashes.
• We would need to implement a new system for handling files, something similar to IData due to its versatile scope of application. By experience we know that even advanced CrT users can't get their heads around some of its functionality which would undoubtedly end up with even more simple issues that are but time consuming, since those scripts tend to be pretty large, so that even a simple missing ; can take quite some time to identify.