The bounds a value must satisfy to be written into this slot of this component.

 The other half of the mapping trySetSlotValue owns, and here for the same reason: what a slot
 IS includes what may go in it, and the two kept apart is how they drifted. They were built
 inline at each properties box instead, which had two consequences:

   - a bound computed from the component's width was frozen at the width the box was showing
     when the expression was typed. Parameterise the width, change the parameter, and an Input's
     stored "must fit in 8 bits" outlived the 8;
   - a value that arrived any other way was bounded by nothing. maxIssieBusWidth was enforced
     only by these lists, so a width bound to a parent's parameter, or written by the sheet
     description DSL, had no upper limit at all and the first thing to object was the simulator.

 Derived, so it cannot go stale: every caller asks about the component as it is now. The
 Constraints stored on a slot are still written as they were, for file compatibility, but are no
 longer what a value is checked against.

 The messages are the ones the boxes used to build, and are written for whoever typed the value:
 see ParameterView.evaluateConstraints, which hands the author's text straight to the user.

A sheet's canvas with every parameterised slot resolved at the given bindings. A slot whose expression cannot be evaluated leaves its component alone, so the widths that are known still come out rather than the whole sheet failing. Here rather than in CanvasExtractor because two callers need it from opposite ends of the compile order: the instance-signature code in CanvasExtractor, and the parameter propagation in ParameterAnalysis that brings every sheet into line with what its design sets.

Apply `value` to the named slot, leaving the type alone where the component has no such slot. Callers that can report a bad slot should use trySetSlotValue; this is for the paths that cannot, where a slot recorded in an old file must not stop a sheet loading or simulating.

True when the component has the named slot, so that a slot can be rejected where it is written rather than quietly doing nothing where it is applied. The value is irrelevant: whether a slot exists depends on the component's type and, for a SplitN output, on the index.

 The type with `value` put into the named slot, or None when the component has no such slot.

 `Buswidth` is a component's own width. `IO` is the width of an Input or an Output - and also
 the LSB of a BusSelection and the comparison value of a BusCompare, because on those two the
 width has already taken `Buswidth` and the properties pane needs a second slot for a second
 field (see SelectedComponentView.makeLsbBitNumberField). That overloading is unfortunate but
 it is what is stored in existing sheets.

 Some integers of a component are deliberately absent, because a parameter records a value and
 not a change of shape:
   - the input count of a GateN or a MergeN sets how many ports the component has, so there is
     no CompSlotName for it and neither component can be parameterised at all;
   - the output count of a SplitN is the same thing, so it has no slot - but the width and the
     bit position of a GIVEN output are ordinary values, and SplitNWidth/SplitNLSB name them.
     Those two are the only slots that can be out of range, and an index past the end of the
     lists is no slot rather than a silently ignored one.

 This is the one place a parameter value stops being a bigint. The three slots whose field is
 already a bigint take it as it is - which is why parameter expressions evaluate in bigint at
 all - and everything else is a width, an index or a bit position, and is narrowed here. A value
 too large to be an int is no more applicable than a slot the component does not have, so it
 comes back as None; it should have been stopped by the slot's own constraint before reaching
 here, so the warning says that it was not.