Bug: Collada uvs from channels a,b,c are imported into Assimp channels 0,1,2.

[StepanHrbek]

Describe the bug Collada: Now that we properly import uv channel numbers used by textures (merged today), it becomes apparent that second half of problem is importing data into correct uv channels. We properly find out that mesh contains data in channels a, b and c (example). But then d6aacefa1ef1219b85028b4038ef7e861c2e9462 changes a,b,c to 0,1,2 and we store data into wrong uv channels.

To Reproduce Steps to reproduce the behavior:

1. Import and render .dae with texture mapped mesh that uses uv channel 1.
2. See that render is wrong, material wants data from channel 1 but data are stored in channel 0.

Expected behavior Collada files should be imported with original uv channel numbers in both meshes and materials.

Additional context I have problem locally fixed by reverting "empty slots are not allowed" paragraph of d6aacefa1ef1219b85028b4038ef7e861c2e9462, I'll send patch. I'll also document that empty slots in mTextureCoords are ok... are they? Also, I don't use GetNumUVChannels(), but I see it's implemented wrong. If we allow empty slots, it needs small fix. Finally, I'm concerned about .dae files that contain channel numbers higher than AI_MAX_NUMBER_OF_TEXTURECOORDS. Do they exist? Are they common? (My approach in LightsprintSDK was to make array of channels resizable, so I never had to figure out how large numbers exist in wild.)