Better scoping of ChanInfo config events

[cboulay]

At the end of NSPDevice _handle_chaninfo(...), we set an event so that methods that set a channel config can wait for a response (e.g., _configure_channel_smpgroup if timeout > 0) before returning. Currently, we use a single event (self._config_events["chaninfo"]) for all chaninfo packets.

However, the NSPDevice configure_channel_by_packet method creates a packet with header.type = CBPacketType.CHANSET, and this gets 13 CHANREP packets in response. The first of those 13 will set the event, allowing the client to regain control. Luckily, so far, the 13 CHANREP packets all come in a burst so the config is fully updated before the client has a chance to query the info and get a half-baked update for a given channel. But we shouldn't rely on this to always be true.

The simplest solution is to re-key our "chaninfo" event in self._config_events as "chaninfo_any" -- which will continue to be set on any call to _handle_chaninfo, and add a "chaninfo_all" event to self._config_events. Then, configure_channel_by_packet should wait on this new event and the _handle_chaninfo method should only set this event when receiving the generic CHANREP packet (last of the 13).

This also raises the topic of whether we should have our events be channel-specific. If we were to refactor a few methods to make them asynchronous, then routines that are intended to affect multiple channels could iterate over these channels with an async for loop that internally awaits the setting of the event per-channel. This would pseudo-parallelize multi-channel configurations which should make them much faster which might be important as we head into higher and higher channel counts. It will also reduce (but not eliminate) the occurrence data packets that are mid-config update, e.g., where only some of the channels we wanted to en/disable have been modified. ETA: I guess we could also only require the event for the last channel in the burst; this would still require channel-specific events.