Subpatch inputs to switch ports are inconsistent.

[asford]

Subpatches are a great mechanism to group common ops for clarify and reusability,
however the current subpatchinput and subpatchoutput interface doesn't consistently support switch ports.
This limits the usability of subpatches, because I'd often need to pass switch parameters into ops within the subpatch.

In the ideal state, I would want to be able to match any switch port in an op into a subpatch input.
This would mean:

1. When I drag a switch port from an op into SubPatchInput, it should create a matching switch input port on the subpatch with the same switch states.
2. The cable running from subpatchinput to the op switch port would carry a value that can be consumed by the switch port.

(1) is probably a UI/metadata introspection feature, the "Create SubPatch Port" operation need to recognize that the op port is a switch and create a switch rather than number port.

(2) is a little tricker, because it requires changing port behavior. Right now it's not trivial to chain switch ports together, because ops (not subpatchops) define the switch input by index, but the switch port output (in code) is a string.
This could be the switch string value (which would require changing standard op switch ports to accept a string switch value in addition to a switch index) or it could be a switch index value (which would require changing subpatchinput to emit an index not a string value).
I think updating the switch input port to accept either a numeric index or a string switch value is the safest, forward-compatible option.

There are workarounds for this, but they'll all clunky or require repeatedly re-declaring the switch the matching options in the same order.
It's possible to crack open the switch op to access .indexPort and recover the integer switch index, but this is a little weird.
It's also possible, as a workaround, to map the string switch value into an input index by "redeclaring" the switch via NumberSwitchByString, but this is... very fragile

I've tried to demo this issue in https://cables.gl/edit/5g2NVd

[asford]

Refiled in #791