Increasing resolution of PWM classes

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) Added new versions of the PWMSlope, PWMParabola, and PWMSmoothRamp
called PWMSlopeHighRes, PWMParabolaHighRes, and PWMSmoothRampHighRes
which will return integers from 0 to 4095 rather than percents from 0 to
100.  They will also do their calculation of what level of dimming you
are at in seconds rather than minutes because the standard resolution
functions only update their value once per minute.
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.

Internally, I am having the functions in RA_PWM use the higher
resolution versions, so you don't need
to supply it on the frontend in order to get the higher resolutions from
the utility methods in RA_PWM like DaylightPWMSlope(),
Channel0PWMSlope(), etc., but if you are using the PWMSlope to do
something else, for instance cloud effects, the function will look the
same to you unless you do PWMSlopeHighRes, and then you should be aware
that you will be getting 12-bit integers from 0 to 4095.

3) Updated the RA_Wifi code to do the calculations right and grab the
right numbers to display to the users.  Displaying percents in 0-100
even when the HighRes functions are being used to make changes
internally because the overrides care about the percent, not the raw
value.

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.  Also, nothing changes 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
in your .ino file,
then it will still work OK because SetChannel is smart enough to know
if you are sending it a byte from PWMSlope or an integer from
PWMSlopeHighRes and
it will do the right thing with it.
Merge pull request #2 from amunter/issue160-new

Increasing resolution of PWM classes