feat: ordered_pins property.

[2e0byo]

Adds an ordered_pins property to Part for the common use-case of iterating a part by real pin number.

pin numbers are currently (in the test suite) either strings or ints. The current logic will throw to the back (randomly) any numbers which aren't actually numbers. If we need to support things like 10a I can implement/use a proper natural sort.

[2e0byo]

I've not made pins sortable, as I don't want to break equality. Specifically two pins with the same number shouldn't compare equal if they are otherwise different. However it's perfectly possible to write a proper __eq__ method which takes this into account (and add proper tests defining pin equality). Would you prefer that? I'll throw it together if so.

Per the other PR, I'll implement proper sorting for BGA pins.

Note that the pipeline failure is unrelated (test_svg fails by lack (I think) of the right binary, and also fails formatting).

[devbisme]

If a Pin has the same part and num as another pin, then they should be equal. You might even get away with just comparing ids for them since there shouldn't be multiple instances of the same pin in a part.

[2e0byo]

Implemented. I don't use id(), since that effectively makes == into is, and there's no code preventing you from creating multiple identical pins. I also throw if you try to sort pins from multiple parts, which may not be desired. The reasoning is that this is probably a mistake, but I'll invert that assumption if you think it's wrong. In any case it's better for the tests to be explicit.

[devbisme]

This looks good. Sorting pins from different parts should definitely be an error.

Is there an easy way to move this PR from the master to the development branch? I don't update the master branch except when I make a new PyPi release.

[2e0byo]

I'll do that after dinner, many thanks.

[devbisme]

Take your time. Nobody's getting paid to do this stuff.

[devbisme]

OK, I figured it out so no need for you to do it. I'll take it from here. Thanks!