Changed the function parameters and handled declaration of CUDA textures

Next steps are:
- modify Projector initialization to reflect changes to kernel
- see if total_area_density[...] array is needed
- macro-ify the places in the kernel that involve repeating a step for each of the volumes

Moved the SingleProjector functionality to Projector class

The CUDA at least compiles.  Currently, the self.minPointX_gpu, etc. is giving me errors about "pycuda._driver.LogicError: cuMemcpyHtoD failed: invalid argument"

I don't get it.  Why didn't this cuda.memcpy_htod(...) bug show up earlier?  I've been using memcpy_htod(...) for a while.

Traceback (most recent call last):
  File "example_projector.py", line 117, in <module>
    main()
  File "example_projector.py", line 92, in main
    images = projector.project_over_carm_range(
  File "C:\git\deepdrr\deepdrr\projector\projector.py", line 317, in project_over_carm_range
    return self.project(*camera_projections)
  File "C:\git\deepdrr\deepdrr\projector\projector.py", line 195, in project
    cuda.memcpy_dtoh(int(self.sourceX_gpu) + (4 * vol_id), np.array([source_ijk[0]]))
Boost.Python.ArgumentError: Python argument types in
    pycuda._driver.memcpy_dtoh(int, numpy.ndarray)
did not match C++ signature:
    memcpy_dtoh(class pycudaboost::python::api::object dest, unsigned __int64 src)

Results:
1. For single volume-case, results differed BARELY for [phi=90,theta=0] and [phi=90,theta=60] -- three and one miniscule pixel regions, respectively.
2. For the three-volume case, this branch performed pretty badly.  The errors are probably from the wrapper code (?), since that's the main difference between the single-volume and three-volume case

The output for the single-volume case looks like the desired output, but really zoomed in on the central cube.  I have determined that the {minAlpha, maxAlpha} are correct by comparing the values at pixel (600,400), a pixel that shows up in the central cube for the alpha branch.

Confirmed that if we omit the portion of code in the "last segment" calculation, this code is equivalent to the alpha branch IN THE SINGLE VOLUME CASE.

Have not tested the multi-volume case.

When splicing volumes of the same material, the boundary between them it pretty obvious, even when it should be invisible.  For example, consider the following two-volume scenario:
  ____________
/___/___/___/|
|___|___ |___| |
|___|___ |___| |
|___|___ |___|/

and we define the volumes:
- volume0: all boxes, all soft tissue
- volume1: the central box, all soft tissue

The boundary between the volumes appears darker than the surrounding pixels, even though the materials are the same.  This happens regardless of whether the input is:
- [(volume0, 0), (volume1, 0)], or
- [(volume0, 1), (volume1, 0)]

Priorities "switch" is now separate from the volumes "switch".

Also established that the boundary artefact effect has something to do with the interpolation at the boundary.

Code works (multi-volume has that artefact), but some TODOs left.

Consult with Benjamin about what to do with the Projector.volume function