extra rabbit clip configurations

[pelletjl]

add a half-lock configuration to rabbit clips and add extra configuration to double-sided pins

[adrianVmariano]

Would it be cleaner to have lock= take string parameters that specify the different lock states instead of introducing lots of booleans that then are potentially conflicting? e.g. lock=true/false works as currently, lock="half" gives you the half lock. I'm not sure what to do about the double case. There are a total of 8 lock states, since there are four locations that may or may not lock. Another idea instead of strings would be a boolean list, like lock=[true,false,false,true] to specify the desired lock state for each position. It would be only length 2 for single-ended pins.

[pelletjl]

I wasn't sure if mixing argument types was an acceptable practice, and I was trying to preserve backward compatibility. I originally allowed conflicts to pass through, but documenting which ones took precedence seemed a bit much. I can try to clean it up if mixing types isn't an issue.

[adrianVmariano]

We often mix argument types. Allowing either a single boolean or a list of booleans is actually a very common strategy where a single false is equivalent to a list of false values (e.g. apply force_list to turn singleton into a list). That's the simplest solution, I'm not sure if it makes sense to have the order go clockwise around the pin or if it should be left right and then left right again for the second pin if present. There's also the question of whether to expand [a,b] into [a,a,b,b] for a double pin, for example when you want one end to lock and the other end to not lock. I think using string arguments here is messier and not necessary.

[pelletjl]

what about, in addition to the current true/false for all edges, allowing LEFT or RIGHT, which would apply to all types as well as TOP or BOTTOM for "double". Also with "double" we could accept a corner or array of corners to lock, e.g. lock=[TOP+LEFT, BOTTOM+RIGHT] or lock=TOP+LEFT?

[adrianVmariano]

I think the proposal above is reasonable, using the direction vectors. When the input is invalid the error message should probably tell the user what options are valid for the current configuration,

[pelletjl]

Done!