mark half(float) constructor as explicit

As shown in https://github.com/OpenImageIO/oiio/pull/2301#issuecomment-527721367 it's possible right now to write code where a function that takes half is called instead of the (missing) overloaded 32-bit float version. While we might have expected there to be an overload present, sometimes mistakes happen and only the half version is present and when this happens often it will work out well enough that this bug won't be noticed. But performance of course will be lower and sometimes will produce very wrong results as the example above showed -- these can be hard bugs to find and fix.

We could prevent this by making the half(float) constructor explicit, so that it's now a compiler error to try and pass a float or int into a function that expects a half. Admittedly this makes it a little bit more awkward to write certain code and we might then want to add extra explicit constructors, but I think it might be justified by the errors it can prevent.

If you think this is more trouble than it's worth, I understand, but I figured I'd at least throw it out there...

Start at the Imath half(float) constructor and review the linked pull-request discussion for the motivating conversion case. Check the existing conversion behavior and relevant tests, then verify that passing a float or int to a function expecting half is rejected while intended explicit construction remains usable.

Written by the indexing model from the issue text.