Swap stb_image and GLI for a "big" image loader

[johannesugb]

Currently, two image loaders are used: stb_image and GLI. In the function gvk::create_image_from_file, first it is tried to load an image via GLI. If that fails, it is tried to load an image via stb_image. GLI can load image formats DDS and KTX (whatever that is).

In the case of loading via GLI, further actions are required: The correct Vulkan-Format must be chosen (see material_image_helpers.hpp#L239 and MIP-maps can not be generated automatically, but must be loaded from file as well (see material_image_helpers.hpp#L171ff).

When loaded via stb_image, always "ordinary" RGBA-formats are created and MIP-maps are created via image_t::generate_mip_maps.

With GLI, there is a problem: Depending on the image format, not all images can be flipped due to some limitations of GLI. That's why there is an if at material_image_helpers.hpp#L231. This turns into a real problem, when loading the UE4 Sun Temple scene or the NVIDIA Emerald Square City Scene from the ORCA scene repository because they contain such textures that can not be flipped.

Another problem is that some not too uncommon image formats are not supported as well, like EXR and TIFF.

This might be a good point in time to swap out stb_image and GLI for one of the "big" image loaders:

• DevIL, or
• FreeImage

To be checked before integrating one of these:

• Is the project still "alive"?
• Does the license comply? Gears-Vk is licensed under MIT, i.e. the license of the image loader library must comply with MIT. I believe that there were some discrepancies between GPL and MIT, s.t. MIT software may not include GPL code? But I could be wrong about that => to be checked!
• Can DDS textures of different formats be loaded (and also uploaded onto the GPU... i.e. not that DDS formats are loaded in an RGB8 format into main memory)?
• Can HDR images be loaded?
• Can EXR images be loaded?
• Can TIFF images be loaded?

This issue should optimally be implemented in conjunction with issue #50.

Definition of done:

• Refactoring: Having the implementation of those functions in material_image_helpers.hpp in the header actually makes no sense and just leads to longer compile-times. => Move them into a .cpp file! Check what is more appropriate: declaring them as external or inline.
• All example applications that load images still work without errors or crashes
• UE4 Sun Temple scene and NVIDIA Emerald Square City Scene can be loaded and have their textures all flipped in the right direction
• Textures are loaded with MIP-maps (both compressed and uncompressed!)
• Compressed images are loaded in compressed format onto the GPU.
• HDR images are loaded in HDR format onto the GPU.
• The post build helper's option "Always Deploy Release DLLs" always deploys the release DLLs and it still works. If you need to tweak the library's build settings, please compare with stb_as_library -- that project should have a properly set-up config.
• How do load times compare to stb_image? Is performance okay?
• The file LICENSE.md has been updated with the information of the added library.
• The image loading functions are well documented and the Contribution Guidelines have been followed.

[johannesugb]

Update about possible image loader candidates:

• DevIL seems to be too dead.
• There have been some reservations been expressed about FreeImage since it does not offer CMake, also it is probably pretty big... and not sure about its performance.
• mango has been suggested as a modern, fast library supporting many formats. But there have been some potential legal issues about the name of the repository, I believe. Don't know any details, though. It is not clear how "alive" this project is.

The alternative is to stick with multiple smaller image loading libraries.

• stb_image is great, obviously, supporting JPEG, PNG, TGA, BMP, PSD, GIF, HDR, PIC, PNM
• GLI seems to be okay, supports DDS and KTX. I believe there was some problem with serialization, s.t. the images can't only be read from serialized data (due to the binary data not being available or so?) => Needs to be double-checked.
• Speaking of KTX, maybe it would be better to use Khronos' very own libktx for that purpose
• The only format which is still missing and support for which would be awesome to have is EXR. tinyexr has been recommended for that.