Fix .ydd export/import with unsolved hashes

[alexguirre]

When a drawable hash was unknown, it kept the "filename.#dd" name so exporting to XML lost the hash and importing it back created a broken file.

Now if the hash is unknown, the name is set to hash_1234ABCD, and XML import checks for hash_.

[dexyfex]

It's so crazy that I feel like I've fixed this same issue twice before in CodeWalker, but it always keeps appearing...
Anyway I think the safest approach to really solve the issue is to be consistent with CodeX, which is to have a separate property/field for the hash, which is only used when it's in a dictionary like this. Then the original ".#dd" name string can be naturally preserved in the XML, but the hash field can contain the actual hash.
I'll implement this approach over the coming days and then close this PR, assuming you don't see any issues with my proposal here. And I guess Sollumz will have to support this as well so as not to cause problems.

[alexguirre]

The only concern I have is that there still are (unfortunately) plenty of people using older Sollumz versions, either because they prefer some old workflow, are trying to follow some old tutorial or can't update to Blender 4.0+ (they increased system requirements and already had a few people on Discord asking if Sollumz would have new updates for Blender 3.6).

With this PR, Sollumz doesn't need any changes. At this point, not sure if changing the CW XML format will just cause more confusion/people asking for help when CW/Sollumz versions don't match, without much gain. Kinda why I have avoided making PRs solving unknowns in drawables/fragments XMLs and only updated Sollumz UI.

Otherwise, having both fields in XML is probably safest, yeah.

[dexyfex]

Hmm, I see the potential issue there, I had no idea about increased requirements for Blender 4.0 so I guess that does complicate matters slightly.. Although I guess users will have to move on from Blender 3 eventually,
There's also PR #232 which involves updating XML (but for fragments), which presumably would have the same issue... I guess the best way forward here might be to try and coordinate our next releases so users can update both CodeWalker and Sollumz at the same time, and at least the users stuck on old Blender can maybe still use an old CodeWalker.
I think these are the only two changes which could affect XML/Sollumz, but if any others come up I'll note them here. I'll also leave processing these updates until last, which will probably be early next week. Hopefully we can decide on the best course of action before then.