Add special-purpose PWM logic to preserve alignment of PWM signals for
things like RGB LEDs.

Keep a sorted list of GPIO changes in memory.  At time 0 of the PWM
cycle, set all pins to high.  As time progresses bring down the
additional pins as their duty cycle runs out.  This way all PWM signals
are time aligned by construction.

This also reduces the number of PWM interrupts by up to 50%.  Before,
both the rising and falling edge of a PWM pin required an interrupt (and
could shift arround accordingly).  Now, a single IRQ sets all PWM rising
edges (so 1 no matter how many PWM pins) and individual interrupts
generate the falling edges.

The code favors duty cycle accuracy over PWM period accuracy (since PWM
is simulating an analog voltage it's the %age of time high that's the
critical factor in most apps, not the refresh rate).  Measurements give
it about 35% less total error over full range at 20khz than master.

@me-no-dev used something very similar in the original PWM generator.

Use fixed point math to adjust running PWM channels to the new
frequency.

Copy over full high/low periods only on the falling edge of a cycle,
ensuring phase alignment for Tone and Servo.

Ensure both the general purpose waveform generator and the PWM generator
are disabled on a pin used for Tone/digitalWrite.

A hump in the dueling PWMs was very prominent in prior pulls.

The hump was caused by having a PWM falling edge just before the cycle
restart, while having the other channel requesting a 1->0 transition
just outside the busy-loop window of 10us. So it gets an IRQ for channel
B 0->1, then waits 2..8us for the next PWM full cycle 0->1, and ends up
returning from interrupt and not scheduling another IRQ for 10us...hence
the horizontal leg of the bump...

Reduce the minimum IRQ latency a little bit to minimize this effect.
There will still be a (significantly smaller) hump when things cross, but
it won't be anywhere near as bad or detectable.

Breaking out bitfields required a load and an AND, slowing things down
in the PWM loop. Convert the bitfield into two separate natural-sized
arrays to reduce code size and increase accuracy.

Apply an error term to generated waveform phase times to adjust for any
other ongoing processes/waveforms.  Take the actual edge generation
times, subtract them from the desired, and add 1/4 of that (to dampen
any potential oscillations) to the next similar phase of that waveform.

Allows the waveform to seek its proper period and duty cycle without
hardcoding any specific calibrations (which would change depending on
the codepaths, compiler options, etc.) in the source.

Thanks to @dok-net for noticing these need to be in IRAM as they may be
called by digitalWrites in an IRQ.

The WiFi stack sometimes changes frequency behind our backs, so ESP's
cycle counter does not count constant ticks.

We can't know how long it's been at a different than expected frequency,
so do the next best thing and make sure we adjust any ESP cycles we're
waiting for by the current CPU speed.

This can lead to a blip in the waveform for 1 period when the frequency
toggles from normal, and when it toggles back, but it should remain
for the intervening periods.

Should avoid a lot of LED shimmering and servo errors during WiFi
connection (and maybe transmission).

PWM has a constant minimum time between loops with a single pin, so pull
that time out of the desired PWM period and shift the center of the PWM
frequency closer to the desired without any dynamic feedback needed.

Enable 60khz PWM, even though it's not terribly useful as it causes an
IRQ every ~8us (and each IRQ is 2-3us).  The core can still run w/o WDT,
but it's performance is about 5x slower than unloaded.

analogWrite doesn't know about the change in total PWM cycles, so it is
possible for it to send in a value that's beyond the maximum adjusted
PWM cycle count, royally messing up things.  Remove the offset.

Also, fix bug with timer callback functions potentially disabling the
timer if PWM was still active.

Volatiles are expensive in flash/IRAM as well as in runtime because they
introduce `memw` instructions everywhere their values are used.

Remove the volatiles and manually mark handshake signals for
re-read/flush to reduce code and runtime in the waveform generator/PWM.

Save IRAM and flash by using a class to hold waveform generator state.
Allows for bast+offset addressing to be used in many cases, removing
`l32r` and literals from the assembly code.

Byte-wide operations require extra instructions, so make index and count
a full 32-bits wide.

Testing indicates that GP16O is just a simple 1-bit wide register in the
RTC module.  Instead of |= and &- (i.e. RmW), use direct assignment in
PWM generator.

By adjusting the PWM cycle slightly to account for the fixed time
through the compute loop, increase the linear response near the min and
max areas.

New startWaveform waveforms were being copied over on the falling edge
of the cycle, not the rising edge.  Everything else is based on rising
edge, so adjust accordingly.

Also, feedback a larger % of the error term in standard waveform
generation.  Balances the speed at which it locks to tones under
changing circumstances with it not going completely bonkers when a
transient error occurs due to some other bit.

Simply mark pins as inactive, don't adjust the ordered list until the
next _startPWM call (in IROM).

Actually check the pin mask is active before setting the PWM pin low.
D'oh.

The cleanup (where marked-off pins are removed from the PWM time map)
and remove (where a chosen pin is taken out of the PWM map) do
essentially the same processing.  Combine them and save ~50 bytes of
code and speed things up a tiny bit.

Save ~100 bytes of IROM by removing the tone/analog pin tracking from
the interface functions.  They were completely unused.

The waveform update structure included 2 32-bit quantities (so, used
8 * 17 = 136 bytes of RAM) for the next cycle of a waveform.

Replace that with a single update register, in a posted fashion.  The
logic now sets the new state of a single waveform and returns
immediately (so, no need to wait 1ms if you've got an existing waveform
of 1khz).  The waveform NMI will pick up the changed value on its next
cycle.

Reduces IRAM by 40 bytes, and heap by 144 bytes.

Let the waveform generator be the single source of truth for the PWM
period in clock cycles.

Reduces IRAM by 32 bytes and makes things generally saner.

Replace repeated PWM update logic with a subroutine, and move the
PWMUpdate pointer into the state itself.  Reduces IROM and IRAM,
removes code duplication.

Also remove single-use macros and ifdef configurable options as the
IRAM and IROM impact of them are now not very large.

Lost an `initTimer()` call in a refactoring, resulting in the core
hanging forever while waiting for the NMI which will never happen.

Re-add as appropriate.

Per @dok-net, drop the rewrite of the edge trigger flag in the timer
interrupt register.  It's set on startup and never cleared, so this is
redundant.  Drops ~16 bytes of IRAM.

When PWM is running and analogWriteFreq is called, re-calculate the
entire set of PWM pins to the new frequency.  Preserve the raw
numerator/denominator in an unused bit of the waveform structure to
avoid wasting memory.

Pulls the actual PWM period closer to the requested one with a simple,
0-overhead static adjustment.

Silly mistake, swapped high and low values when checking analogWrite for
over/under values.  Fixed

Save a few bytes of IRAM by not using -O2 on the stopWaveform call.  It
is not a speed-critical function.

Results in much closer PWM frequency range over any number of PWM pins,
while taking 0 add'l overhead in IRAM or in the IRQ.

When _setPWMFreq was called the initial PWM mask was not set to 0
leading to occasional issues where non-PWM pins would be set to 1
on the nextPWM cycle.  Manifested itself as an overtone at the PWM
frequency +/-.

Borrow a trick from esp8266#7022 to exit the busy loop when the next event is
too far out.  Also reduce the IRQ delta subtraction because it was
initially not NMI so there was much more variation than now.

Keep the PWM state machine active at a higher prio than the standard
tone generation when the next edge is very close (i.e. when we're at
the max or min of the range and have 2 or more near edges).  Adds a
lot of resolution to the response at low and high ranges.

Go from relative to absolute cycle counts in the main IRQ loop so that
we don't mingle delta-cycles when the delta start was significantly
different.

Keep PWM error <2.0% on entire range, from 0-100%, and remove the
hump seen in testC by fixing the min IRQ delay setting.

The IRQ lead time was a tiny bit undersized, causing IRQs to come back
too late for about .25us worth of PWM range.  Adjust the constant
accordingly

Since the adjustment for when a 160mhz compile is running at 80mhz
is giving bad behavior, simply remove it and revert to old behavior.

Includes patches to allow side-by-side existance of the two versions and
a slight change such that the #define ..._PWM is unneeded (i.e. allow
existing makefiles/scripts/etc. to get expected behavior w/o any changes
on their part).