This commit implements proper PDU Session Release handling across
RRC, PDCP, F1AP, E1AP to ensure clean resource cleanup when
a PDU session is terminated.

Key changes:

NGAP:

In `rrc_gNB_process_NGAP_PDUSESSION_RELEASE_COMMAND()`:
  * Populates E1AP Bearer Modification for each released session
  * If a CU-UP is connected, triggers `bearer_context_mod()` for PDU teardown

PDCP:
 * Added `nr_pdcp_release_drbs()` to remove all DRBs linked to a given PDU session
 * Called from `e1_bearer_context_modif()` for correct clean-up during session release

F1AP UE Context Modification:

  Replace direct RRC message transfer with F1AP UE Context Modification Request
  to properly handle PDU session release according to 3GPP TS 38.331.

  3GPP TS 38.331 `5.3.5.6.4 DRB release` says: whether or not the RLC and MAC entities associated
  with a PDCP entity are reset or released is determined by the CellGroupConfig. Thus,
  updated CellGroupConfig needs to be received by the UE. This has to be retrieved by CUCP
  from the DU. Therefore:

  After receiving an NGAP_PDUSESSION_RELEASE_COMMAND, the CUCP shall:
  1) forward (store for later) the NAS PDU to the UE, if present as per 3GPP TS 38.413, and
  2) send a UE Context Modification to the DU with the list of DRBs to release
     and the RRC container (RRCReconfiguration with NAS PDU)

  After reception of UE Context Modification Response, the list of drbs to release
  is prepared based on PDU session status PDU_SESSION_STATUS_TORELEASE
  in rrc_gNB_generate_dedicatedRRCReconfiguration and then encoded
  in drb_ToReleaseList for a new RRCReconfiguration with the new cellGroupConfig.

  Key changes:
  * rrc_gNB_generate_dedicatedRRCReconfiguration_release() now uses F1AP UE Context
    Modification Request instead of direct RRC transfer
  * Only DRBs to be released are now added to the list.
  * The ASN.1 memory allocation is entirely done in build_RRCReconfiguration_IEs
  * No longer needed to store ASN1 struct in UE context

GTP-U:
  * Previous implementation had incomplete tunnel cleanup during PDU session release
    - Missing distinction between N3 (PDU session level) and F1-U (DRB level) tunnels
    - Lack of proper DRB identification for F1-U tunnel deletion
  Major Changes:
  * GTP tunnel teardown now handled in `e1_bearer_context_modif()` using the correct
  F1 or N3 GTP instance (`newGtpuDeleteOneTunnel()`)
  * Enhanced Tunnel Deletion Logic (cucp_cuup_handler.c):
   - Separate handling for N3 tunnels (1 per PDU session) and F1-U tunnels (1 per DRB)
   - Added proper DRB identification for F1-U tunnel cleanup
   - Improved error handling with detailed logging for each tunnel deletion
   - Enhanced logging to distinguish between N3 and F1-U tunnel operations
  * New PDCP API Function (nr_pdcp_oai_api.c/h):
   - Added nr_pdcp_get_drb_ids_for_pdusession() function
   - Enables retrieval of all DRB IDs associated with a specific PDU session
   - Supports proper F1-U tunnel cleanup by providing DRB identifiers in CUUP
  * Enhanced GTP Interface (gtp_itf.cpp/h):
   - Modified newGtpuDeleteOneTunnel() to accept tunnel_type parameter
   - Improved logging to distinguish between PDU session and DRB tunnel types
   - Better error messages for tunnel deletion failures
   - Enhanced debugging information for remaining tunnels

Clean-up:
* Ensured xid tracking works consistently between PDU Session Establishment (with NAS PDU)
  and dedicated RRCReconfiguration
* Add function to release GTP-U tunnel in Bearer Context Modification Request handler
* Do not send rrc_gNB_send_NGAP_PDUSESSION_RELEASE_RESPONSE when no PDU session are to
  be released: it is sent upon completion of the RRCReconfiguration and needs to contain
  released PDU Sessions (mandatory IE), therefore it is no necessary to send it in case
  there is no PDU session to release.

Related to #867
Co-authored-by: rmagueta <rmagueta@allbesmart.pt>