Require witnessed checkpoints for self-update FT log

[mhutchinson]

Currently the self-update component goes directly to the FT log to update the OS and Applet, which means that a split view could target some/all devices to update to versions of the firmware that the verifiers will never see. The fix for this is witnessing, and we have witnesses! One option is to change the UnilateralConsensus for a version that goes to the distributor to fetch N witnessed checkpoints.

However, there's a bootstrapping problem, and a potential deadlocking problem. To do this, the witness needs to know about:

1. The identity of all of the witnesses that use the distributor
2. How many witnessed checkpoints is reasonable to ask the distributor for

Discussing 2 first, If we pick too high an N, then we risk the update component never being able to get a sufficiently witnessed checkpoint, thus locking it out of future updates, and thus not being able to get a new version of N to rely on!

The other issue is how to get all of the witnessed identities. Options are:

1. Bake the identities into the code, and let the auto-update mechanism distribute the new identities
2. Run a log of witness IDs (per environment, i.e. {CI, prod}) that the witness will access to get the IDs

The latter is what we had discussed to date, but this is the start of a "turtles all the way down" situation. We wouldn't want to trust this log directly because we could be served a split view. So we would want to get a witnessed checkpoint for this log. But where would we get the witness identities to verify the signatures? Obviously, the log. But this is a chicken and egg problem.

The pragmatic solution here looks to be to bake in the Witness IDs and a very conservative N into the applet image and rely on the auto-update mechanism to keep it up to date.

We may want to bake in a dead-man's trigger that lowers the N (and eventually disables this witnessing requirement) after a period of time so that a bad update doesn't lock out the witnesses from updating. We would want to surface that this trigger had fired in some way that would be hard to miss, or else we risk the security mechanisms being disabled silently.