Make it possible to pre-generate cube maps for environment lighting

Right now what happens is that the first time a HDRI file is used as a texture source we run a series of render passes that generates a cube map that contains pre-convolved environment map faces and mip levels for varying roughness values, and a single mip level with an irradiance map.  This series of passes is quite expensive and should ideally be done offline at build time if possible.

Because the generated texture is both a cube map and contains mip levels it would need to be stored in a container format like KTX.

What should be done is a new plugin should be created for using the asset import infrastructure to convert HDRI files into this container format, and then adjust the logic to use this file directly at runtime when provided.

This is important because startup time can be drastically affected on embedded platforms when using image based lighting (up to 1 min for large HDRI files, or 25 seconds for reasonably sized HRI files).  This is not acceptable, so we must provide a way to "bake" these assets at build time to prevent this.

It is unavoidable at runtime when using a HDRI file directly, but we at least need a "fast" option if we continue to use this approach.

This approach requires that:
1) Qt KTX loading needs to support textures with uncompressed data
2) Qt KTX loading needs to be able to load cube map textures with mip levels
3) Whatever version of baking is used, it needs to be able to actually render, because the baking method requires multiple baking passes

This change would also update the logic when specifying a light probe. So when the user specifies a KTX file instead of an HDR file, and the KTX file contains cube map data, we just skip the runtime bakeing, and assume that the KTX file contains the complete data needed.