Pick instance feature

[thatcomputerguy0101]

This adds pick_instance and ray_intersect_instance functions to allow detecting which geometry instance a ray intersects with. There is a new example picking_instances that demonstrates this capability for basic geometry, instanced geometry, and imported models. The additional example has yet to be added to the examples README. This closes #467.

Additionally, the shader IDs have been separated out to simplify keeping track of which ID's were used, and a few ID overlaps were corrected. The shader IDs internally make use of open_enum types, which could be changed to also be the public type signature in a breaking release. The shader ID changes can be seen individually at https://github.com/thatcomputerguy0101/three-d/tree/shader_ID_refactor, and I can create a separate pull request for that or remove those changes if desired.

[asny]

@thatcomputerguy0101 I made a separate PR for the shader ID refactor to make it easier to review and test that change separately. I'll update this PR after that is merged.

[thatcomputerguy0101]

This PR has now been updated to be based on the current master branch.

[thatcomputerguy0101]

I'm looking at using ints the whole way through the GPU side, although that requires using an integer output texture which restricts support to OpenGL 3.0 or greater and WebGL 2. Would these be acceptable versions to still replace the original pick, or should pick_instance remain separate to support older versions that only need pick?

[asny]

I'm looking at using ints the whole way through the GPU side, although that requires using an integer output texture which restricts support to OpenGL 3.0 or greater and WebGL 2. Would these be acceptable versions to still replace the original pick, or should pick_instance remain separate to support older versions that only need pick?

Yes, that would be ok. Would you write the depth to an integer then? You need to write depth (f32) and ID (u32) to a render target, so you have to choose either a float or integer target. I'm not sure it makes a big difference whether you choose one over the other.

[thatcomputerguy0101]

Part of that change would be reading the depth from the depth buffer (supported in WebGL 2 if I interpreted it correctly), which is always a float data type.

[thatcomputerguy0101]

Seems like I misinterpreted being able to read from the depth texture on web. I still have some ideas to work around that though.

[thatcomputerguy0101]

GL's floatBitsToInt function ended up being useful. It is fully working on both MacOS and web with an integer output texture, and the floating point depth value encoded in one of the color channels. I'll probably create a separate PR for integer texture support, as I made some significant changes to get that working.

[asny]

@thatcomputerguy0101 These changes seems a bit too much for the feature, so I tried implementing it myself (picking snippets from this PR and #478). You can see the result in #494, it's significantly simpler and works well. So is there a good reason for all of these changes?