When a prefix gets deleted from the RIB, dpdk_lpm algo needs to know
the nexthop of the "parent" prefix to update its internal state.
The glue code, which utilises RIB as a backing route store, used
fib4_lookup_rt() after the prefix deletion. This approach didn't
work for "nested prefixes": if 10.0.0.0/24, 10.0.0.0/23 and 10.0.0.0/22
exists in RIB, deleting 10.0.0.0/23 resulted in 10.0.0.0/24 being
returned. This, in turn, resulted in failure to update the entire
/23 with a next nexhop, leading to eventual crashes.

Fix this by creating per-family rt_get_inet[6]_parent() helpers
and using them in the dpdk_lpm code.