Fix pad-ID scan for end-cap

The PADID scan scans over all PB PADIDs and checks if communication with a PB could be established. Currently, it assumes that the PB will have PADID=0. This is true for the barrel, but end-cap PBs have different unique PADIDs per type.

This MR addresses this issue.

It further accounts for a specialty of the R3 PBs on the R3 carrier-board. R3 basically consists of two barrel powerboards, so 2x AMAC, 2x HVMux, 2x LinPol, etc. Each of the AMACs on the R3 has a separate PADID. The data-lines on the R3 carrier card are shortcut for the two AMACs of one PB. That means that the data-line in powerboard slot x, where x is even, are connected to those of powerboard slot x+1.

If running the PADID scan first on the even PBs (yielding PADID=5), the PADID scan gets confused in the next step when running on the odd powerboards. This is, because it tries to assign a different AMAC-ID to PADID=5 (which it already scanned), instead of just finding PADID=6.

An easy solution is just to skip PADID=5 if running on the odd R3 powerboards, labelled R3_1. Since R3_0 (the even R3 PBs) and R3_1 will always be tested together (see a future MR), all PADIDs are still tested in that way (as R3_0 has PADID=5). This is also addressed in this MR.

Depends on !157 (merged) and !158 (merged).

Tagging @kkrizka