Improve ZPE Service Routers

[m-hau]

Improve the existing types of ZPE's Service Router product line by updating the existing types, and adding a few new devices and modules.

The used part numbers are the ones reported by the devices themself, which only identify the "base chassis" and are not listed in the data sheet. The data sheet SKUs are more akin to pre-configured bundles with different memory-/storage-/expansion-configurations. This is not so prevalent with the NSR because it is a modular chassis, and more noticeable with the GSR and BSR. The actual slots of the device are modelled as module-bays, and can be populated using the appropriate modules to document the actual configuration.
The same is true for some of NSRs modules (namely storage and M.2), where the data sheet SKUs are pre-assembled bundles but the modules themselves report a generic part number. That is the reason these module types have again module-bays of their own, into which you can insert the actual harddisks/M.2 modules. Note that importing module-bays of modules was only added in v4.2.9 (see netbox-community/netbox#19311). While the actual M.2 cards do have their own SKUs, the hard disks don't, so it would be better for the storage module to use the new "Hard disk" module type profile; but that is not available yet (see #3364).
While the RAM is technically also a FRU, I opted to not model the RAM slots as module-bays since they are not intended to be changed, and the few people that actually do that and want to document it that detail degree can create the module-bays themselves using the comments. The same goes for the integrated storage in NSR.

For the most part the only real difference between the "base chassis" is the cpu, which is why as model I used the full product name and the cpu-core-count (and PSU type for the non-Lite NSR). I did not add all of the NSR chassis power variants, namely the SAC/POE/DC variants are still missing in the library, and need to be added later if required. Apart from the power supply they should be identical to the DAC variant.

The device definitions use the bridge attribute on the interfaces to model which ports are connected to the integrated switch chip. Note that the import into NetBox does currently not support this, but hopefully soon (see netbox-community/netbox#20042).

The (non-Lite) NSR and GSR have a single switch chip inside, but two backplane interfaces to it. To properly model this the backplane0 can be considered the main switch interface, and backplane1 is bridged by backplane0. Any ports that are added through modules will need to be manually assigned post-creation to the backplane0 bridge/interface.
By default the NSR comes with rear-exhaust fans, which is why the airflow is set to side-to-rear. When using a rear-to-side configuration using different fans, this needs to be set manually; and the fans can be documented using the module-bays.

I wasn't sure what to do with the digital IO ports of the GSR. In the end I modelled them as console server ports, since that was the closest fit, and allows you to cable them if wanted.

[harryajc]

If you can make these changes on all devices that it applies