feat: add bootloader hash to ProgramInfo

[glihm]

This PR solved two issues:

1. The fact is registered using the program hash of the bootloader, that boatloads the Layout Bridge program. Piltover was using the Layout Bridge program hash. This PR addresses that by adding the bootloader program hash to the ProgramInfo.
2. The Layout Bridge program wasn't verified (only SNOS was), which could have cause any bootloaded program to be accepted by Piltover. There is now an explicit check of the Layout Bridge program hash extracted from the program_output.

This PR makes also easier to debug Piltover execution when the fact is not found for the given parameters, which previously panicked with Index out of bounds.

[chudkowsky]

i think at this point where we check output 3 times, we could wrap this in some function validate input to abstract that from update function

[chudkowsky]

LGTM, i would think about wrapping some stuff into function to make update state function more clear

[glihm]

LGTM, i would think about wrapping some stuff into function to make update state function more clear

Thank you for the review. Yes and as discussed with @xJonathanLEI, we may rework at this occasion the inputs. Since the layout bridge is for now required due to the lack of support for dynamic proof verification, having an enum instead of several inputs could make it more flexible for testing also, when only the SNOS output could be sent instead of having to mock the layout_bridge one too.