boot/bootutil: give the hash of the received key to boot_retrieve_public_key_hash

[Olstyle]

MCUBOOT_HW_KEY already allows to put your own signature key management into the bootloader, independent of mcuboot. In the moment boot_retrieve_public_key_hash is limited to exactly one key hash, since it is only called once and there is no way for the called function to determine whether it will be returning an accepted hash.
Adding the hash itself to the call enables the project specific code to look for a fitting hash instead of just returning one. This way two things can be accomplished:

1. Multiple HW keys can be used since now iterating through a list of hashes is feasible
2. Automatic revocation (see Support for revoking/invalidating keys #221 ) can be added since the function now knows which key was used and might decide to invalidate other keys based on that fact

The key revocation scheme I plan to use based on this patch is based on a sorted list of key hashes. Normally the first entry is expected to be used for signing. If an entry deeper down the list is used, this indicates that the private keys up to that entry have been compromised and they should be invalidated.
Invalidation itself is HW specfic. For example on an STM32 it is possible to overwrite already written flash with zeros, which can be used to delete a non zero validity flag.

[d3zd3z]

I do think this is slightly better. But, I have a little bit of a concern that we are effectively breaking an API, and this would result in a major version change. It is hard to tell who out there uses this function, so we will need to make sure there are clear directions on how to update this. So, at a minimum, there need to be release notes on this.

But, I really wonder if this whole interface is actually right. Presumably a system with a hardware key wouldn't have the key available (perhaps the public key?), and it seems really weird to me how the key returned from this function is then written to a global. If anything, this makes this code untestable in the simulator (this is not introduced by this change, but already there). I'm not sure how to do this better.

[Olstyle]

To be honest this is just the smallest change I could think of. If we accept this is a breaking change anyway, the interface could be changed to directly return a bool about whether the key hash is accepted.

From what I understood from the original MCUBOOT_HW_KEY setup, the argument for only using hashes was that those might be saved in OTP memory or something similarly expensive. That's not actually what I am doing. I just needed an interface which lets me look at some info about the key (or the key itself) and make a decision instead of giving a key directly.

Maybe bootutil_find_key needs to be rethought for a third time. Originally I expected it to return a (pointer to a) key, but neither version of it does this.