Fix a very important bug in the GI path of the raytracer

The problem is in hemisphereSample(). The incorrect formula to use
the generated spherical coordinates is used.

The issue is that there are two common notations of theta/phi angles
and their meanings. One, more common notation, is that
theta is in [0..2pi], phi is in [0..pi] (0 = north pole, pi = south pole),
and the corresponding cartesian coordinates are

(cos(theta)sin(phi), cos(phi), sin(theta)sin(phi))

The other, less common notation changes the meaning of phi: it is now in
[-pi/2 .. pi/2], with ±pi/2 meaning the poles, and 0 is the equator. The
formula for cartesian coordinates changes slightly: swap sin/cos for phi:

(cos(theta)cos(phi), sin(phi), sin(theta)cos(phi))

In hemisphereSample(), the code for uniform sphere point picking, taken
from the mathworld site, generates theta/phi in notation (1). Then we
generate our outbound ray using notation (2). The effect is a severe
deformation of the distribution function, in which I guess a lot of the
rays condense on the poles. Since we don't rotate generated rays according
to a normal transformation matrix, this means that a lot of the paths
that continue out from a point in pathtrace() traverse in the up/down
direction. This manifests in an overall diminished GI effect, and some
unexpected specular effects (diffuse surfaces seem somewhat specular, when
viewed from top). There was a slight splotch on the ceiling of
smallpt.trinity, and a much-more heavily present rectangular reflection
of the tall box in cornell_box.trinity. It almost looked as if the material
of the box is not Lambert, but a Refl with glossiness > 0.9.

tldr; the GI was very buggy due to a mismatched formula. Remapping phi to
[-pi/2..pi/2] to fix it.
Related to the previous fix: remove hacks that made GI more prominent
(than it should be).

pathtrace(): there's no justification for pdfBRDF. It just made the
             GI brighter, and with the previous bug, this was what
             made the GI visible at all.
Lambert::spawnRay(): the probability to generate a random hemisphere
                     ray is 1 / (2pi), not 1/pi. eval() and colorEval
                     are multiplied by 1/pi for a different reason:
                     this is the factor, which makes the BRDF
                     integrate to unity over the hemisphere (so energy
                     is preserved 100% if the albedo is 1). The factor
                     would have been 1/(2pi) if it weren't for the
                     cosine-weighted nature of BRDFs.
smallpt.trinity: since the change to pathtrace makes the scene quite a
                 bit darker, increase the light power here.

The result now exactly matches smallpt's output, save for a very slight
difference in gamma treatment (Kevin Beason's tracer pow()s by 1/2.2,
while we do an exact sRGB compression).