fix!: Make configureKey explicit

[Koenkk]

Before the configureKey was automatically calculated based on the hash of the function. This has 2 big drawbacks:

• When refactoring, devices are unnecessary re-configured
• Given that a lot of devices uses modernExtend now, the direct body of configure doesn't change (and therefore the hash doesn't), so no re-configure is done when actually needed.

This PR makes the configureKey explicit again (like it was a long time ago) so we can decide on the definition level wether a device should be re-configured.

[Nerivec]

The old name configureKey isn't really great for its purpose.
I'd be tempted to just version definitions instead?
I suppose we could use just a plain number (which triggers reconfigure).
Or maybe expand this with semver versioning (version: `${number}.${number}.${number}`). We can attach pre-defined Z2M "needs" to major/minor/patch, like reconfigure on minor, re-interview on major... just random examples, but you see what I mean)? Could offer a bit more room for future needs. I'm thinking this might help with cases like custom cluster renaming that is often annoying with ZH's cached data (could clear that as appropriate with a version change). Also could help avoid issues in edge cases like downgrading Z2M (Z2M logic could handle > vs < differently, as appropriate).
Doesn't need to be added to all converters at once, just when first needed (need to make sure we properly support when the version changes from undefined to something else though).

Might also have to add some specific versioning in this Z2M release for changed converters (have to check all since 1), so they don't ignore reconfigure because of default 0.

[Koenkk]

I think a re-interview can also be done from the configure itself (or just the specific action needed, e.g. node descriptor request) but I get the point. I'm not sure if version is explicit enough (as it doesn't really indicate what needs to happen). I would prefer to have e.g. configureVersion, interviewVersion. What do you think?

[Nerivec]

Too much maintenance in my opinion, and grows definition payloads, database size, exponentially with each "trigger" that's needed (future problems).
Adds more confusion too, would have to always ensure only one is updated as appropriate, else risk duplicated triggers, out-of-order, etc..

version is simple, yet allows complex behaviors by itself. If we have a clearly defined/documented behavior attached to major/minor/patch, I don't think it's a problem at all. It will be like a regular software version, and something most users can identify when debugging & co (semver is known well-enough, they'll know e.g. something big changed if major was bumped).

I guess first we should identify the list of currently needed triggers though, see how it would currently work. You know converters better than me but I figured something along the lines of:

• major: clear all cache and basically do the equivalent of a device join
• minor: re-interview without cache (will trigger re-configure internally)
• patch: re-configure

[Koenkk]

I see, shall when than start with just a single digit version? Because only the re-configure is needed now.

[Nerivec]

Your call, guess it depends if you see a need for re-interview and more in the near future. Would need to refactor for compat if you want to implement other needs (semver would not be number). semver package is already present, so, might be just as fast to use version: `${number}.${number}.${number}` directly.