Fix import of large maps

[Shfty]

Currently importing a map of modest size (E1M1 from Quake, for example) will lock the editor as soon as the file has been saved.

The hang is down to some hacky code left in the import plugin that calls load() immediately after saving the map to a .tres in an attempt to force an update of scene instances that reference it. I don't think that code does anything useful since the asset IDs change on every reimport at the moment anyway, so will likely be removing it.

The problem may extend further than that though- I had the editor lock up upon selecting the imported E1M1.map last night, which may point to Godot having issues with massive .tres files. Need to do some more research.

[ghost]

If it has issues with large tress files is it possible to break them up past a certain size limit?

[Shfty]

It turns out that the second issue was with the editor's handling of massive datasets. It grinds itself to a halt loading all the entity/brush/face subresources, then doubles down by trying to instantiate UI controls for them.

The actual process of reading a map file into an intermediate data representation is quite fast even with large examples like ad_sepulcher, so it's just the editor exposure that's an issue.

Unfortunately, Resource subclasses need their properties to be exposed in order to work properly, so they're no longer an option for storing the intermediate data representation of a map file.

I've moved the initial QuakeMapReader-driven parse and data conversion process into QodotMap, and reduced the import plugin down to storing a simple auto-incrementing revision counter for each map. This way, Godot will be able to see the files and auto-reimport them, but won't kill itself trying to understand them at the data level.