Support for reading/writing single Enigma files

[NebelNidas]

Currently, mapping-io only supports Enigma directories. This PR adds support for single Enigma mapping files. This should bump the library's major version, since MappingFormat.ENIGMA now relates to the file instead of the directory structure, which is now called MappingFormat.ENIGMA_DIR - same goes for the respective reader and writer classes.

Closes #22.

[Devan-Kerman]

why not just MappingFormat.ENIGMA_FILE, then you don't have to change the major version

[NebelNidas]

why not just MappingFormat.ENIGMA_FILE, then you don't have to change the major version

This would break the convention that MappingFormats are single files by default, which IMO definitely should be left this way. If you want to do something "weird" like exporting mappings to a directory, that should be explicitly stated, not the other way around

[Devan-Kerman]

I don't think that convention is important, and I would say it's def worth less than maintaining compatibility

[NebelNidas]

But it's irritating for the library consumer when there's no coherent naming scheme, I don't want to commit such no-gos. We're in the 0.x development phase after all. And I want to commit another breaking change later on anyway, so this is a good occasion for doing it now all at once ;)

[NebelNidas]

8f2e51c This was the second breaking change I was talking about, and I think it is needed since the format package became really cluttered (and would have become so even more after more formats get added)

[sfPlayer1]

It's be best to have the suffix on both, makes it least surprising. Other formats don't have multiple sub-types in this form so can be left alone.

I think it is better to not split the format implementations by version (put both tiny1+tiny2 in tiny). Internal classes like EnigmaWriterBase or ColumnFileReader should be package private if possible or documented as impl only otherwise. We could probably introduce the jetbrains annotations (same as in fabric api) to make it clearer.

[NebelNidas]

Internal classes like EnigmaWriterBase or ColumnFileReader should be package private [...] We could probably introduce the jetbrains annotations

Done!

Other formats don't have multiple sub-types in this form so can be left alone

Hmm, I feel like if we're adding suffixes anyway, we should apply them consistently. Leads to more confusion otherwise.

I think it is better to not split the format implementations by version (put both tiny1+tiny2 in tiny)

Generally I agree, but the only thing tiny v1 and v2 have in common is their name (and tabs), basically everything else is different 😅

Edit: I've merged them into the same package anyway.

[modmuss50]

Lets merge, but get all the planned breaking changes in before releasing