Proposed API: bgfx::getTextureInfo

[ryantrem]

This is a follow up from another discussion topic: #2376. Two things from that discussion (creating a new texture to blit a render texture into, and allocating a buffer passed to readTexture) are awkward because you have to track a bunch of texture info yourself, even though bgfx knows all this internally. The purpose of this proposed API is to make the scenarios above simpler.

What I propose is adding a new function with the following signature:
void bgfx::getTextureInfo(TextureHandle _handle, TextureInfo& _info) (plus the C99 equivalent).

This is similar to bgfx::calcTextureSize, except calcTextureSize would be used when you haven't actually created a texture yet, and getTextureInfo could be used if you have already created the texture and have the associated handle.

This would also perhaps be conceptually similar to the existing bgfx::getUniformInfo.

Under the hood, it would do the following:

1. Use the existing m_textureRef array to get a TextureRef for the given TextureHandle - this gives us every part of TextureInfo exception bits per pixel.
2. Use bimg::getBitsPerPixel to get the bits per pixel value.
3. Fill in the provided TextureInfo from the TextureRef and the bits per pixel value.

Thoughts?

[bkaradzic]

This is similar to bgfx::calcTextureSize, except calcTextureSize would be used when you haven't actually created a texture yet, and getTextureInfo could be used if you have already created the texture and have the associated handle.

Philosophy of bgfx API is to not provide getters (or to provide as minimal as possible), only in cases where it's necessary (for example, bgfx::getUniformInfo).

When you create texture you exactly know what you're creating, you know do you need this information for every texture, or only some textures, etc. bgfx keeping certain data internal allows internal changes without affecting API. For example, if someone wants to make runtime more lean by trimming some internal data from release builds.