Humility may need multi-image support improvements

It appears that, right now, you can:

1. flash A/B firmware images onto a part
2. Boot it into image A
3. Run Humility using image B's archive
4. Get weird results

e.g. using the correct archive:

$ humility -a target/rot-carrier/dist/a/build-rot-carrier.zip tasks
[2023-04-14T22:40:08Z WARN  probe_rs::config::target] Using custom sequence for LPC55S69
humility: attached via CMSIS-DAP
system time = 29787
ID TASK                       GEN PRI STATE    
 0 jefe                         0   0 recv, notif: fault timer(T+13)
 1 idle                         0   9 RUNNING
 2 update_server                0   3 recv
 3 syscon_driver                0   2 recv
 4 gpio_driver                  0   3 recv
 5 user_leds                    0   6 recv
 6 usart_driver                 0   5 recv, notif: usart-irq
 7 rng_driver                   0   5 recv
 8 sprot                        0   6 notif: spi-irq
 9 swd                          0   4 recv
10 dumper                       0   5 recv
11 ping                        37   8 wait: reply from usart_driver/gen0
12 pong                         0   7 recv, notif: timer(T+213)
13 hiffy                        0   6 notif: bit31(T+213)
14 sp_measure                   0   6 not started

using the incorrect archive:

$ humility -a target/rot-carrier/dist/b/build-rot-carrier.zip tasks
[2023-04-14T22:40:03Z WARN  probe_rs::config::target] Using custom sequence for LPC55S69
humility: attached via CMSIS-DAP
system time = 24628
ID TASK                       GEN PRI STATE    
 0 jefe                         0   0 recv, notif: fault timer(T+72)
 1 idle                         0   9 RUNNING
 2 update_server                0   3 recv
 3 syscon_driver                0   2 recv
 4 gpio_driver                  0   3 recv
 5 user_leds                    0   6 recv
 6 usart_driver                 0   5 recv, notif: usart-irq
 7 rng_driver                   0   5 recv
 8 sprot                        0   6 notif: spi-irq
 9 swd                          0   4 recv
10 dumper                       0   5 recv
11 ping                        30   8 wait: reply from usart_driver/gen0
12 pong                         0   7 recv, notif: timer(T+372)
13 hiffy                        0   6 notif: bit31(T+101)
14 sp_measure                   0   6 not started

but then add something like -s that requires PC knowledge and

$ humility -a target/rot-carrier/dist/b/build-rot-carrier.zip tasks -s jefe
[2023-04-14T22:42:26Z WARN  probe_rs::config::target] Using custom sequence for LPC55S69
humility: attached via CMSIS-DAP
system time = 154021
ID TASK                       GEN PRI STATE    
 0 jefe                         0   0 recv, notif: fault timer(T+79)
   stack unwind failed: Do not have unwind info for the given address. 

My guess is that every PC value being observed by Humility here is outside of any defined object, and it would be nice if Humility noticed that and reported it. (That would also catch cases where there's a valid Hubris kernel image leftover in RAM but the system's actually crashing in e.g. the bootloader after a reset, which also currently acts like things are fine.)

Start by reproducing the humility -a ... tasks commands with matching and mismatched A/B archives, then compare the -s jefe output. Done means Humility detects when observed PCs fall outside the selected image's defined objects and reports that state instead of treating the results as valid.