feat!: Standardize ZDO.

[Nerivec]

Move ZDO requests out of Adapter to standardize execution.
All sending of standard ZDO requests is done via sendZdo.
ZDO responses are emitted from Adapter to Controller, where common logic can be executed as needed. Removes the need for separate events.

Also worth mentioning:

• Automatically introduces new features to drivers that previously weren't supporting them (like change channel). Will need testing however.
• Make use of IEEE Address Response (similar to Network Address Response) in Controller.
• Add support for changes in network address that weren't advertised by the device or missed by Z2M. (supersedes and should fix Check for a changed network address when routing fails in zstack #1183)
• Fix some previously hidden coverage.
• Fix eslint in controller.test.ts for easier future updates.

TODO separate PR:

• Move ZDO requests to upstream code
• Remove deviceAnnounce and networkAddress event from Adapter
• Remove old functions from Adapter & impl.
• Fix tests
  • Controller
  • ember
  • zstack
• Deal with permitJoin special-case (later PR? in conjunction with [Proposal] Removal of "forever" Permit Join #940)
• Verify compatibility with zigbee2mqtt tests

[Nerivec]

Regarding #1183 (and accompanying issues)
Logic implemented here is as follow:
On reception of a ZCL payload, if the attached network address does not correspond to a device known to Z2M, send a request for the IEEE that goes with that network address. As a result, this will trigger a ZDO response that will update the network address of the device matching that IEEE, if Z2M knows it, otherwise, the ZCL payload is skipped (as before).
That should hopefully cover these cases (see included tests):

• device changed network address but didn't advertise it
• device changed network address but Z2M missed it (offline)

Here is a sample of the logs in action with ember (forced to trigger by manually changing the nwk address in the database before starting Z2M):

debug: 	zh:controller: Trying to identify unknown device with address '3612'
debug: 	zh:ember: ~~~> [ZDO IEEE_ADDRESS_REQUEST UNICAST to=0xFFFFFFFFFFFFFFFF:3612 messageTag=2 payload=021c0e0000]
debug: 	zh:controller: Received ZDO response: clusterId=IEEE_ADDRESS_RESPONSE, status=SUCCESS, payload={"eui64":"0xa4c1387d3b6e41cc","nwkAddress":3612,"startIndex":0,"assocDevList":[]}
debug: 	zh:controller: IEEE address from '0xa4c1387d3b6e41cc:3612'
debug: 	z2m: Device '0xa4c1387d3b6e41cc' reconnected
info: 	z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/0xa4c1387d3b6e41cc/availability', payload '{"state":"online"}'
info: 	z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/0xa4c1387d3b6e41cc', payload ''
debug: 	zh:controller: Device '0xa4c1387d3b6e41cc' got new networkAddress '3612'
debug: 	zh:controller:database: Writing database to 'data\database.db'
debug: 	z2m: Device '0xa4c1387d3b6e41cc' changed network address
debug: 	zh:controller: IEEE address from '0xa4c1387d3b6e41cc:3612'
info: 	z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/0xa4c1387d3b6e41cc', payload ''
debug: 	zh:controller: Received payload: clusterID=6, address=3612, groupID=0, endpoint=2, destinationEndpoint=1, wasBroadcast=false, linkQuality=220, frame={},"payload":[]}}

Note that if the device sends other ZCL payloads during the time it takes for the response to come in, these will be ignored to prevent spamming.

[Koenkk]

Verify compatibility with zigbee2mqtt tests

Zigbee herdsman is completely stubbed in z2m and since the interface didn't change this should be OK.