Fix: ESP32 espShow() doesn't de-init RMT

[brentru]

@ladyada The issue fixed by this PR is allowing a new NeoPixel object on ESP32 to be destroyed and re-created. The core issue is within esp.c's espShow() implementation for IDF 5+ which looks like it was modified/written by teknynja.

What should work:

• Calling pixel.updateLength(0) then pixel.show() should be invoked in user-code to release RMT resources.

Why this does not work:

• When calling updateLength() with a value of 0, the function frees the pixels buffer
• Calling show() directly after will [early-return since the first check within show()is forpixels`](https://github.com/adafruit/Adafruit_NeoPixel/blob/master/Adafruit_NeoPixel.cpp#L421)
• Because of this, espShow() will never [release RMT resources] or re-attach them (https://github.com/adafruit/Adafruit_NeoPixel/blob/master/esp.c#L61) as expected.
• When the NeoPixel object is destroyed and re-created, the object will fail to execute show() calls because the RMT was neither released or re-attached properly.

Addresses:
adafruit/Adafruit_Wippersnapper_Arduino#691
adafruit/Adafruit_Wippersnapper_Arduino#684

[tyeth]

Does this change mean the updateLength(0) call then show() might be ineffective on other platforms? There doesn't seem to be the same advice about cleanup for other platforms.
Also just now reading the docs it says update length is deprecated and to use the new syntax and length argument.
I don't think many people destroy and then re-setup NeoPixel objects, nor set length to zero and then alter to many pixels, so maybe just untested

[dhalbert]

The .update_length(0); .show() to free resources seems too subtle to me. Either the resources (RMT, in this case) should just be freed in the destructor, and that's the only way to free resources, or there might be a .end() routine, which doesn't do anything for most platforms, except for Espressif.

[brentru]

@dhalbert

The .update_length(0); .show() to free resources seems too subtle to me.

Since it wasn't correctly implemented, I was implementing the broken length/show code.

Either the resources (RMT, in this case) should just be freed in the destructor,

I agree; we should go in this direction instead of freeing the RMT via 2 functions. calls may be good for two reasons:

1. update_length() is marked as a deprecated function to begin with
2. this issue deals with new and delete and the best spot for handling that would be in the ctor/dtor, respectively.

I'll go ahead and implement this, ping both you and @tyeth when

[brentru]

@tyeth Can I re-request a review for this?

[dhalbert]

This seems OK to me. It still seems a little round-about, but I assume there are use cases for adjusting the number of LEDs on the fly and we support that.