pk3dir support (+pk4dir/dpkdir support)

[illwieckz]

This PR adds pk3dir support, in a simple way: each pk3dir is loaded as a VFS.

This PR also extends the pk3 VFS to support dpk/dpkdir for Dæmon engine/Unvanquished game, and I also added pk4/pk4dir because it was cheap.

I haven't yet found a way to not load found pk4 and dpk if VFS is pk3 only (or other combination), so the current code loads all pk3/pk4/dpk found if game profile uses pk3 VFS. It's probably not an issue though.

DPK vfs is the versionned and dependency based VFS used by the Dæmon engine (used by Unvanquished for example, see DPK Format), this dpk support introduced by this PR does not handle versionning (it just loads all dpk/dpkdir available as if it was pk3), it does not prevent mapping and compiling, people just have to take care of concurrent paths like pk3 needs, and people are used to, so there is no urge to implement this versionning and dependency mechanism and it's considered out of topic regarding this PR.

The same mechanism was added to q3map2: pk3dir, dpk and dpkdir support added. I did not added pk4/pk4dir support since there is not pk4 based games known with map compilation needs. The pk3dir/dpk/dpkdir code is copypasted straight from NetRadiant tree, and also lacks versionning/dependency mechanism for dpk use case (it's true on NetRadiant side for q3map2 too).

I initially derivated my code from a code by @neumond, but I was not happy with this first implementation, or its latest state: this first implementation was just loading the pk3dir for the current map, and needed everything else (like texture set) being there as pk3. So I removed the per map pk3dir loading mechanism and added the “load every pk3dir found” mechanism instead. At the end, I discovered that all the code by @neumond was entirely removed, without any trace from it.

[illwieckz]

Note: I discovered a strange bug around the pk3dir support, but I don't know if it's related to the code introduced or just triggered by some new path that was never taken before.

My textures/radiant/notex shader is stored in a tex-common_src.pk3dir or tex-common_src.pk3 set. This textures/radiant/notex shader is not a physical path but a shader path, the real picture path is different (textures/common_src/notex.png, and this shader path is only provided to workaround the GtkRadiant inability to provide this required texture itself.

• When I open a blank map, GtkRadiant is able to find the textures/radiant/notex path even if it's only provided by a pk3dir.
• When I open an existing map, GtkRadiant complains because failing to load the textures/radiant/notex path when this path is only provided by a pk3dir.
• When I open an existing map, GtkRadiant is able to find the textures/radiant/notex path if it's provided by a pk3.

[ensiform]

Question about pk4s, was it always just a zip same as pk3? Or were any of the iterations (d3, q4, etc) using a different algorithm like rar or something? Could've swore someone a long time ago said it worked with rar too.

[illwieckz]

Oh? never seen any pk4 with another format than PKZIP, and never heard of that. o.O
Perhaps the guy was just meaning it was able to produces PK4 using the WinRar software?

All the official Doom3 and Quake4's pk4 are PKZIP archives, same for The Dark Mod.

Also, if idTech4 had included a rar unarchiver, it would have been an issue when idTech 4 code was freed.

[ensiform]

Only the doom 3 code was freed. But yeah that's probably what the person meant back then.

[illwieckz]

note that before merging it, GtkRadiant must get proper shaderlist.txt handling.

[illwieckz]

See #573 for a blocking issue: please do not merge this PR before #573 is fixed.