Feature: region files support

[edgarogh]

Hello, I implemented a feature that closes #1798. I did this for my personal use but this PR is spontaneous, I can understand that this is not wanted as I've never got the chance to discuss that with a maintainer. No hard feelings if you aren't interested.

Feature breakdown

• Ability to expand region files as if they were archives (which they somewhat are, to be fair)
  
  • Only chunks that have been initialized (world-generated) are shown
  • Since region files should only contain NBT, and since the chunks are only indexed by their XY position, the file names are completely arbitrary. I chose to use the traditional c.x.z.nbt naming, but this can be changed.
  • These NBT files can obviously be opened in the already-existing NBT viewer (read-only though)
  • Due to the sheer simplicity of the region format, the parser was implemented directly in my code
• The chunk coordinates inside the files are absolute (or relative to the entire world, if you prefer)
  
  • This makes searching for a specific chunk much easier
  • The name of the MCA file is taken into consideration to know the location of the whole region itself
  • If the MCA file has an invalid name, I'm showing relative coordinates instead (I'm using tildes, as most Minecraft players would understand them as meaning "relative")
    
• This is a bit unrelated, but this PR removes the "Save" button in the toolbar of NBT files if the file is read-only, which is important in this case -- as my code doesn't handle writing to region files -- but it might as well improve the compatibility with other extensions in scenarios where a read-only NBT file is opened
• NBT payloads inside region files are compressed using an algorithm specified within the region file (outside of the NBT payload, if that makes sense). If I didn't do anything special to handle that, the NBT editor's combo-box would always show "Uncompressed" because my code is handling the decompression before handing over the NBT payload to IntellIJ. I added a special case for that, so that the correct compression algorithm is shown. Because editing is not supported, the combobox is disabled anyway. To be frank, I'm not really happy with my code, it feels spaghetti-esque, but I'm willing to improve the structure if you have suggestions.
  
  • Note: region files support algorithms that aren't typically used in typical standalone NBT files, namely ZLib and LZ4. I've made sure that they don't appear in the combobox of standalone NBT files

What remains to be done

I prefer opening this PR before I spend too much time on the feature, as it is already sufficient for what I needed, but there are a few more things to do before it's mergeable.

• I did not bother with threads at all for the moment, i.e. the files are read on the main thread. The index of region files (the part needed to enumerate the chunk list) fits in the first 2KiB of the file, so should be really fast to read, but it would undeniably be better to do this properly, with threads. Reading the actual chunk content uses exclusively InputStreams that I'm handing back to IntelliJ, so I would assume that they're doing things correctly in terms of parallelism
• I'm not really handling parse errors. At best, I'm just returning eagerly from functions when something looks off, but my code probably deserves better error reporting.
• I haven't extensively tested my code.

Disclosure

1. This is my first time ever using the IntelliJ SDK, I can't guarantee that everything I did is correct or idiomatic. I have decent (hobbyist) experience in Kotlin, though.
2. While I did not copy code from them, I wouldn't have been able to implement the custom archive type without the help of https://github.com/b3er/idea-archive-browser and their code being open source (Apache-2.0). They probably deserve a little bit of credit somewhere. Maybe in my own files, in a comment.

---

Please tell me if you're interested by this and if you have any remarks. I'll continue improving the code only if this is useful to others.
Have a great day!