Fix type of CompressedTexture.mipmaps

[HunterLarco]

Currently CompressedTexture and CompressedArrayTexture represent mipmaps using the browser's ImageData. This is actually inaccurate to three.js's implementation in a few ways:

1. ImageData#colorSpace is unused by three.js.
2. ImageData#data is the incorrect type. It is Uint8ClampedArray however, using Uint8ClampedArray will sometimes cause runtime breakages in three.js (see below for details)

Of these two, (2) is the real problem. ImageData#data is defined as Uint8ClampedArray, however, mipmap data is regularly used by threejs in texSubImage2D and compressedTexSubImage2D which both require that the source data array view matches the texture type. For example, if I have a texture using RGIntegerFormat with FloatType then compressedTexSubImage2D must be passed a Float32Array. As currently written, clients would be forced to use Uint8ClampedArray which will cause a runtime error due to misalignment between the source data and texture type. This is documented by texSubImage2D which specifies

One of the following objects can be used as a pixel source for the texture:

• Uint8Array (Must be used if type is gl.UNSIGNED_BYTE)
• Uint16Array (Must be used if type is either gl.UNSIGNED_SHORT_5_6_5, gl.UNSIGNED_SHORT_4_4_4_4, gl.UNSIGNED_SHORT_5_5_5_1, or ext.HALF_FLOAT_OES)
• Float32Array (Must be used if type is gl.FLOAT)

The fix here is to replace the current usage of ImageData with a new type MipmapImageData which better aligns to three.js's internal usage, and importantly allows the data field to be populated by any TypedArray.

[Methuselah96]

Thanks! I did some cleanup to the PR, hopefully while preserving the intent of your changes.

[HunterLarco]

This looks great! Thanks for tidying up the PR