Multi godot version support

[dougVanny]

I've added support for multiple Godot version output formats!

Basic usage of the library remains the same. However, now instead of simply converting a GDFile to string, you need to call the output_to_string and pass an extra argument specifying how the file should be output. Other methods like GDFile.write were also updated accordingly

The OutputFormat class defines how the output should be generated, with flags for each behavior different godot versions have. To make things easier, there is also a VersionOutputFormat where you just inform your godot version and all flags will be filled accordingly

Several tests where added for each flag inside OutputFormat. Also, I've created test projects on every major Godot version from 3.3 to 4.6 (through the web editor at https://editor.godotengine.org/releases/) and am testing each one of them through pytests, comparing results and getting 100% matched without any form of sanitization

On top of it, I also made a guess_version class method under VersionOutputFormat that will take a guess at which godot version was used to create an input parsed file by peeking at which features it's using. This means that, with a single file as input, you can make as many changes to it as you want and output with while keeping whatever format was originally used

This also solves the issues with test_parse_files.py discussed on #21. I have removed all forms of sanitization from the diff and am relying simply on raw string comparison, getting 99% of success. The remaining 1% is caused by inconsistencies within godot, the one I found being some tres files for some reason having extra line breaks under [ext_resource] entries that I can't do anything about

I'll try to break down everything that is being changed in this PR

• Created OutputFormat and VersionOutputFormat classes to setup how files should be output
• Added output_to_string() method to all godot classes (Through a base Outputable class)
• Adjusted line breaks added between sections of a GDFile
• format and load_steps parameters on a GDFile header are now being updated on output generation as these values are driven by the OutputFormat object
• Resource IDs are now stored as weak references by default, only being filled either when on output or when calling generate_resource_ids. This is also driven by OutputFormat
• Renamed GDScene to GDPackedScene as scenes stored in a tscn file are treated as resources by the name of PackedScene within Godot (I feel like the Tree API in this lib, that I didn't touch any more than needed, would be a good place to use the "Scene" nomenclature)
• Moved node related methods from GDCommonFile to GDPackedScene
• Created PackedVector4Array (and Vector4) to deal with a how different godot versions output this object specifically (Used to identify if file should be saved with format 4 or 3)
• Created PackedByteArray to suport outputing this as base64 (Used to identify if file should be saved with format 4 or 3)
• PackedArrays and PoolArrays interchangeable between Godot3 and Godot4 output and saved accordingly depending on the OutputFormat
• Backwards compatibility of Godot4 objects. TypedDictionaries will be saved as regular Dictionaries if unsupported, StringNames will be saved as strings and so on
• Fixed how String and StringNames are output. String are written with all special characters as is, other than \ and " for parsing reasons. StringNames escapes all characters on storage such as writing "\n" instead of adding a line break to a file
• Spaces between parenthesis and brackets are now dictated by OutputFormat
• Updated all occurances of __delitem__ to not fail silently
• Added several project files under tests/projects to test different Godot projects
• Tests under test_parser.py are now running as sub tests so one parse fail doesn't block others from being tested
• Craeted ID Generators used by OutputFormat to ease testing and avoid randomly generated IDs

[stevearc]

I appreciate that you're trying to make this work better, but please realize that this is over 3000 lines of changes to review and maintain. If I had a lot of time I could eventually manage to review a PR this large (for reference, the entirety of this repo currently clocks in at only 2000 LOC), but the maintenance is the real problem. I can't merge this because I can't maintain this much new code.

[dougVanny]

No worries! I made these changes so I could use this lib in a project of my own and thought it wouldn't hurt to share those improvements back, but the maintenance concerns are understandable. I'll simply keep working on my own fork for now. Thanks!