Use F1 Internally: switch to CU UE ID in CU

This MR modifies F1 to properly handle CU and DU UE IDs by storing them in a UE context, and switches the ("primary") CU UE ID to be the NGAP UE ID (previously it used the RNTI).

• Introduce a new module f1ap_ids.c that uses hashtables to store the CU and DU UE IDs
• In all F1 messages: provide the CU UE ID and DU UE ID explicitly instead of an RNTI that the F1AP module resolves. The latter has the drawback that there can be conflicts at the CU if two DUs chose the same RNTI, and certain use cases (e.g., reestablishment) might not be handled gracefully via F1
• CU (CU-CP/UP): switch the primary UE identifier from the RNTI to the CU UE ID, which is the NGAP UE ID
• CU-UP: simply "mirrors" the CU-CP UE ID to use the same. Note that our CU-CP cannot handle a CU-UP that choses a different CU-UP UE ID, and will assert
• Handover: has been simplified to retain the same ID at CU. At DU, we simply use the "old gNB-DU UE F1AP" to free a previously assigned RNTI after handover (see 38.473)
• stats: add some more helpful stats for UEs in nrRRC_stats.log, as it will be more and more important for CD and debugging

there are some open points to be addressed:

• test reestablishment thoroughly
• need to simplify nr_rrc_gNB_decode_ccch(): I suggest to decode and switch in rrc_gNB_process_initial_ul_rrc_message(), and branch to either an RRC Setup handler or an RRC Reestablishment handler.
  • (RRC Setup) there is a check for a UE with the same RNTI, this should IMO simply not be done
  • (RRC Setup) need to check what should happen for S-TMSI
  • (RRC Reestablishment) can be simplified
• add reestablishment test case in F1