Improve lights and sensor deletion

[manup]

When deleting a light or sensor, don't store entries with state 'deleted' but purge a device completely.

Since deCONZ 2.10.4 one of the following conditions must be met to create a deCONZ::Node:

1. Permit Join is enabled and messages are received from an unknown node (Device Announce etc.);
2. A device table entry exists and a Node Descriptor can be retrieved from device_descriptors table or as fallback from older session.default file;
3. A not deleted entry in nodes or sensors tables exist.

This is done in order to prevent reappearance of deleted nodes.

---

This PR also enables creation of light nodes even if light search isn't running anymore, but minimal required data has already been queried from the device (Node Descriptor and Simple Descriptors).

The reason this came up is that in larger installations where >100 devices where joined successfully and appeared in the GUI some of these weren't processed completely and light resources where missing albeit the device was already joined during a Permit Join enabled phase.

[ebaauw]

This PR also enables creation of light nodes even if light search isn't running anymore, but minimal required data has already been queried from the device (Node Descriptor and Simple Descriptors).

So now if permit join is set from the GUI, the deCONZ::Node will be created on e.g. Device Announce, the core will read the descriptors and the API will create the /lights resources, but not the /sensors resources? Also, for end devices, the /lights resource might be created at a seemingly random time, when the descriptors can (finally) be read when it polls its parent? That could cause a lot of confusion.

[manup]

So now if permit join is set from the GUI, the deCONZ::Node will be created on e.g. Device Announce, the core will read the descriptors and the API will create the /lights resources, but not the /sensors resources? Also, for end devices, the /lights resource might be created at a seemingly random time, when the descriptors can (finally) be read when it polls its parent? That could cause a lot of confusion.

Indeed, I haven't thought about the "non-light" light resources. I think it shouldn't happen in practice but to be safe this part is now removed from the PR. Note there is already a --always-add-lights=1 command line parameter to enable this if needed (I used that a few times to fix some larger installations remotely).

[manup]

@ebaauw I think the PR can be merged now, since it only now only handles proper deletion of light and sensor nodes.