Fix reference unlock by same public key but different address

[muXxer]

My take on #697.

Currently it is impossible to unlock an implicit account creation address and an ed25519 address which are derived from the same public key in the same transaction. This is because we disallow to have the same public key in different signatures, but we also fail to check correctly for a valid reference unlock, if the underlying public key is the same, but the address is different.

This PR changes the logic in a way that the public key that unlocked the identity gets tracked, and in a reference unlock it is checked that the specific derived address for that public key matches.

The PR introduces the concept of a SignerUID in the Signature and AddressSigner interface to identify unique signatures signers (in out case public keys).

The AddressSigner for the TransactionBuilder now needs to be passed in the constructor instead of the Build method. This breaking change was necessary because otherwise the workscore for transaction payload was wrong in certain edge cases, because the formerly used EmptyAddressSigner had no knowledge about the SignerUIDs and therefore didn't construct the ReferentialUnlocks properly. The EmptyAddressSigner was therefore removed.

The PR also removes the unused Key interface from the chain ID and other IDs, because the Key method of the underlying Address is used everywhere instead, which is more precise.

The review was done before a big refactor of the code :/

[cyberphysic4l]

Just a few small renames and comments suggested, but the logic changes seem quite minimal now that it's cleaned up so much and all looks good to me.

[alexsporn]

lgtm, makes it simpler to read 👍