good news: no longer limited by setInterval,  bad news: 65hz seems to be the cap.

I've changed it so that we don't try to change the color until the previous datagram has been sent.  However, because it's udp we don't know when the datagram is received,
so you can still get into a situation where you flood the lifx with too many commands.  When lifx gets flooded it appears to ignore all incoming commands and so the color doesn't change.
I've created a synchronous (blocking) function called waitFor()  so  to help wait for arbitrary amount of time for the lifx to receive the datagram and change the color.  I've played with the timings but it seems
like you can't get lower than 15ms of waiting before flooding the lifx.

other ideas to improve framerate:
-  we could mimic ACK events  by sending the lifx a "gettime" or "getcolor"  command, and waiting for the response.   and then not send another color until we get the response from lifx. this might help us achieve the
absolute fastest speed without flooding the lifx, but that fastest speed may just end up being 65hz.

alternate ideas:
- we can use the undocumented "pulseColor" command with "sawtooth" stepping  to effectively double the hz, but that might make drawing a bitmap super confusing.
- similarly,  we could use pulseColor command with  "sine" stepping to create a a gradual transition between  hue=0 and hue=360 at hz.  This would create a "rainbow light"  when we use the spinner.