Changes

Split up_peer into pfcp_{node,entity}_peer

Match our data domain with the specifications in 3GPP TS 29.244:
"""
CP function: A node with a Control Plane function (see 3GPP TS 23.214 [2]) supporting one or more PFCP entities. A
Control Plane function, i.e. a Control Plane Node, is identified by the Node ID that is set to either an FQDN or an IP
address.

UP function: A node with a User Plane function (see 3GPP TS 23.214 [2]) supporting one or more PFCP entities. A
User Plane function, i.e. a User Plane Node, is identified by the Node ID that is set to either a FQDN or an IP address.

Node: Either a CP function or an UP function supporting one or more PFCP entities. A Node is identified by the Node
ID, which is set to either an FQDN or an IP address.

PFCP Entity: An endpoint in a CP (or UP) function supporting PFCP, that is identified by the IP address. The IP
address of a PFCP entity may or may not be the IP address included in the Node ID.
"""

In general, we have a "pfcp_node_peer 1-1 pfcp_entity_peer" relation, and
this is what so far is implemented here. In the future we can improve
code to support a "pfcp_node_peer 1-* pfcp_entity_peer" relation, which
can actually be implemented in 2 different ways (2 different features)
as explained in 3GPP TS 29.244 section 5.22.

Due to those 2 different features, it's actually difficult to figure out
where to install the FSM with the association state (entity vs node).
For now, leave it at the pfcp_entity_peer level, in order to simplify
the implementation and make the changes in this patch easier to follow.
Hence, pfcp_node_peer is so far only used to track Node-Id changes, and
is released as soon as all its PFCP Entities are released.

Related: SYS#7719
Change-Id: Ie64be4fd55157e9646e250f8cbe93ba3f3c19b17