Upstairs should specify the region UUIDs it expects from incoming downstairs connections

See the discussion in #557 for additional context. Upstairs knows how to ensure that a given downstairs's reported UUID doesn't change over time, but there's currently no way to specify expected downstairs UUIDs in a VolumeConstructionRequest, even if they're known to the creator of that request.

This is the snippet that checks for consistency when a downstairs reconnects (and that will need to be amended to check for consistency when a downstairs first connects):

https://github.com/oxidecomputer/crucible/blob/8cf2566ad49ca18565178269b6e3cbc4dea921d5/upstairs/src/lib.rs#L5630-L5653

This may require some bolt-tightening around the way client IDs are defined and used. (As things currently stand, up_main creates client IDs such that client_id X corresponds to the Xth element of CrucibleOpts::target; if target were expanded to include expected UUIDs, then it would be possible to prepopulate ds.ds_uuid with the correct ID-to-expected-UUID mappings; but this feels a little bit loosey-goosey, at least to me, and I suspect there's a way to specify all this more formally.)

Start with the discussion in #557 and the reconnect consistency check in upstairs/src/lib.rs around lines 5630-5653. Trace how VolumeConstructionRequest, CrucibleOpts::target, client_id, and ds.ds_uuid are defined and used. Done means expected downstairs UUIDs are specified formally and checked both on initial connection and reconnect.