Issue 160:  Changes to PWM classes to increase resolution and implement SmoothRamp 

This branch addresses Issue [#160](https://github.com/reefangel/Libraries/issues/160)

**1)** Added PWMSmoothRamp for Daylight, Actinic, Daylight2, Actinic2, and
am tempted to add highATO and lowATO pins for all of the PWM functions
just for completeness because there's no good reason you can't dim with
them if you wanted, I guess.

**2)** Changed the PWMSlope, PWMParabola (which is actually the top half of
a sine, not a parabola), and PWMSmoothRamp (which is the left half of a
cosine when ramping up and the right half of a cosine when ramping down)
to do their calculations in seconds rather than minutes and also to use
a PWM range of 4095 for dimming calculations.
Using seconds instead of minutes are needed if the 4095 levels of
dimming is going to be useful because the original functions only
updated the value once per minute, which for a one hour ramp is only 60
levels of dimming, essentially.
When writing to the pins the ones that support only values up to 255
will get mapped down from 0,4095 to 0,255.  The new PWM dimming
expansion, however, can take values up to 4095, so this one will get the
full numbers written to it.  I'm using a new method called
PWM.GetChannelRaw, GetDaylightRaw, etc. to return these values from 0 to
4095 as integers and dividing out to get the byte values that GetChannel
always returned.

**3)** Fixed a parenthesis bug in PWMSmoothRamp.  The value wasn't calculating correctly since it was added a few merges ago.  It was dividing by 2 before adding 1 to the cosine.  Now it should work correctly.

**Note for users:**  GetChannel, GetDaylight, etc. still work the same way,
they return percentages.  Overrides are still set in the same way, they
are set using percentages.  What will change is if you are using the
output of one of the PWMSlope, PWMParabola, or PWMSmoothRamp directly in
your .ino for something.  If you're using it as an input to SetChannel,
then it will still work OK because SetChannel is smart enough to know
that you are sending it an integer from one of the slope functions and
it will do the right thing with it.  If you're getting the raw number
from a PWM profile and doing something with it, however, be aware that
it now returns numbers from 0 to 4095.