Changes to DCPump class and methods

1) Added HighATO as an option for all DCPump modes
2) Added initialization for DCPump memory location of the Threshold
concept so if you're using internal memory with the RFExpansion module
enabled you will get a 0 written for threshold for the first time and if
you don't have an RFExpansion module enabled you'll get a 30 percent
written to the memory location.  This only happens the first time you
load the code that contains this new memory location (which is /mb364,
by the way).
3) Added defines for Else and Sine mode as DCPump modes and defined them
as mode 12 and 13, respectively, which matches what was added in U-App
as Else mode.
4) Outputting a new tag in the wifi output of <DCT> which reports the
threshold.  It comes in the XML and JSON right after <DCD> which is the
duration.

Tested with:

ReefAngel.DCPump.UseMemory = true;
ReefAngel.DCPump.DaylightChannel = Sync;
ReefAngel.DCPump.ActinicChannel = AntiSync;
ReefAngel.DCPump.LowATOChannel = Sync;
ReefAngel.DCPump.HighATOChannel = AntiSync;
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 remote-tracking branch 'origin/issue160-new' into dev-working