Speed up RTC exchange, exclude non-VPN paths from the RTC scheme

[bor1go]

1. Add Key(RouteTarget)->uint64.
2. Add map[Key(rt)]map[*Path]{} to globalRib VPN tables for fast making path list by RT.
3. Add map[Key(rt)]int to Adj RTC tables for fast filtering paths by RTs.
4. Add tests on pp.1-3.
5. Non-VPN paths must not depend on RTC.

This is about complexity of RTC.

1. Currently, filtering a single VPN path before sending requires O(n) operations, where n is the number of RTs in the RF_RTC_UC table. Constructing a list of VPNs takes O(nm) operations, where m is the number of VPN paths (filterpath).
2. When a new RT is received, filtering VPNs to respond (propagateUpdate) requires O(m) operations.

This PR proposes a new approach that potentially reduces the complexity to O(1) for filtering and retrieving VPN paths, assuming the map container is used effectively. However, this approach requires additional memory. Specifically, for each VPN GRT, it necessitates:
n*L*m*sizeof(*Path) , where L is the average number of extRTs in the Path, m - number of paths, n - number of known RTs +
n*sizeof(RouterID) - to store interested on RT peers +
n*sizeof(uint64) - for indexing RTs
Additionally, for each Adj RF_RTC_UC table, the memory requirement is approximately:
n*(sizeof(uint64)+sizeof(int))

[bor1go]

@fujita could you please take a look at it, if it is possible?
I attempted to optimize the RTC by reducing linear and quadratic complexity for large numbers of paths.