Add PON (Passive Optical Network) as a standard Network Port type [Feature Request]

Current situation:

Currently, GLPI supports various network port types (Ethernet, Wifi, Port Aggregation, Alias, Dialup, Loopback, Fibre Channel). However, there is no dedicated type for PON (Passive Optical Network) technologies like GPON, XGS-PON, or EPON.

Why it's needed: With the massive growth of FTTH (Fiber to the Home) and POL (Passive Optical LAN) deployments, managing equipment like OLTs (Optical Line Terminals) and ONTs/ONUs (Optical Network Units) in GLPI is difficult using only the "Ethernet" or "FC" types. PON ports behave differently – they are point-to-multipoint and require specific attributes.

Proposed change:

1. Add PON as a new entry in the Network Port type dropdown.
2. (Optional but recommended) Allow adding specific attributes for this port type, such as:
   • Optical Power (TX/RX)
   • ONT ID / ONU ID
   • VLAN Configuration (Service/Management)
   • Splitter Ratio

Benefit: This will allow network administrators and ISPs to accurately document modern fiber-optic infrastructure within GLPI without using "workarounds" or generic port types.

Currently, this lack of a dedicated PON type significantly impacts the GLPI Inventory module. When using the GLPI Agent to discover and import network equipment (such as OLTs or high-end routers), all fiber-optic interfaces are automatically classified under the generic 'Ethernet' type.

This creates several issues:

• Data Inconsistency: Network administrators cannot easily filter or report on actual fiber infrastructure vs. copper connections.
• Manual Overhead: After every synchronization, users have to manually correct the port types to reflect the real-world physical layer, which defeats the purpose of automated inventory
• Improper Mapping: Standard Ethernet attributes don't always align with PON-specific logic (like shared bandwidth or passive splitting), leading to a messy documentation structure.

Integrating PON as a native type would allow the GLPI Agent to correctly map these interfaces during the XML/JSON import phase, ensuring that the CMDB remains a 'Single Source of Truth' without constant manual intervention.