Enigma file format for in-repository data

[sciwhiz12]

Currently, we are considering the use of Enigma as a user-friendly interface for inputting mappings. This has been used to great success by Fabric's Yarn mapping project, and would mean that we are able to use code which has been tested to work (rather than rolling our own solution).

However, there are two things (to my knowledge) which are currently blocking our adoption of the tool: restricting Enigma to only allow parameter names and documentation (which is a task that's being worked upon), and using a format which Enigma understands. Of revelance to this repository is the second point.

To resolve the second point, we have three options:

1. Modify Enigma to support the Parchment mapping data format. This would mean PRing these changes upstream, or maintaining a custom fork of Enigma which adds support for our format.

   The second choice would add a burden of maintenance on ParchmentMC's development team which would potentially mean that we would have to closely look at FabricMC/Enigma and rebase our changes constantly. For long-term maintainability, this is not preferred.

2. Create intermediate tasks which transform the data in our repository to a format understood by Enigma and back again to our own mapping data format.

   This represents a compromise between changing our data format, and being able to use Enigma. This also means we can potentially reuse the inputs systems to read in the data. However, this adds an not-insignificant cost to contributing (once which is already compounded by our whole inputs system and Gradle task chain), which may discourage small contributions on the basis of too much work involved.

3. Move the data in-repository to the Enigma file format, natively understood by Enigma and specifically designed for storing data in git repositories.

   This would necessitate moving all the current data across our two branches to the new format, and implementing support for the format in Compass (so that it can run validations and export the data). However, this gives the advantages of: using Enigma without any modifications on the format front, using a tried and tested (by the Yarn mapping project) mapping format which is designed for ease of storage and mergability in a Git repository, and would remove some undesired artifacts in our current mode of storage (such as pure additions in terms of data requiring a line deletion due to comma placement).

As the issue title suggests, I am leaning towards moving the repository to the Enigma mapping format instead of introducing overhead via intermediate tasks, which also grants us the benefits of the format (such as merge conflicts being easy to fix).