The reflection will be calculated even if it ends up not contributing to
the final color of an object. This allows for a more systematic use of
coefficients without applying them twice, like it was done for the
refraction transparency handling...
The refractions are now implemented using the Fresnel equations to take
into account the amount of light that is reflected off of transparent
surfaces.
For example, this leads to a small amount of discoloring at the edges of
the ball in the example scene. Indeed, this ball has a refractive index
higher than diamond (!), so its edges reflect light much more than when
looking at it dead-center.
This necessitated to rework how light properties for a material were
given. A material can have either reflectivity or transparency. This
changes the parsing of materials, using a `LightProperty` structure at
its core.
This is does not implement the true Fresnel equations to take into
account the amount of reflection that an incident goes through when
encountering a transparent object.
This was a recurring bug in a previous implementation, clamping the
colors before taking the sum of a series of calculations avoid adding a
negative value to a positive one and getting a result which does not
make sense.
The implementation was very easy to write, but is not yet optimal. It
would be better to use `join` to divide into tasks directly on the
stack. And it would be better to iterate over entire blocks of rows
instead of giving a row per-thread: this would lead to better cache-line
behaviour with the fully linear memory accesses.
This allows for easier testing (notable allowing for comparisons),
better performance (thanks to inlining instead of vtable indirection),
and should ease the deserialization of `Material`, `Shape`, and
`Texture` traits. This should allow `Object` to be deserialized easily.
