This is the second part of routing subsystem changes initially described in D24141.
First part of these changes has landed in D24232.
## Implementation
* Follows the same implementation as nexthop objects and reuses parts of the infrastructure.
* Nexthop groups are stored in the resizable hash and are indexed in the same way nexthops do.
* Similarly, there is a private part (contains pointes to nexthops and relative wights) and dataplane-visible part, consisting of array of nexthops to choose from.
* Max nhgrp wifth is set to 64 (no limitations here, can be bumped futher)
* Lazy initialisation: allocate index/hash memory at first attempt to add multipath route.
* `rt_nhop` can now point to either nexthop or nexthop group (distinguished by `NHF_MULTIPATH` flag.
* all dataplane functions handle nexthop selection internally
* routing table notifications can now notify on switching between nexthop groups -> `rib_decompose_notification()` has been created to decompose such notifications to a set of old "simple" add/del/change operations.
## User-visible changes
* Backward compatible: all non-multipath functionality continues to work as is
* All routes comes up with weights, default is 1, max is 16M (2^24).
* route delete <prefix> will work for non-multipath prefixes, specifying gateway is required for multipath ones
### Hashing
* Relies on mbuf flowid for both transit and outbound traffic.
* For locally-originated connections we don’t currently calculate inp_flowid. As performance optimization, start calculating these hashes after inserting first multipath route (V_hash_outbound).
### Rollout stages
1. Commit with `net.route.multipath=0` by default even with `ROUTE_MPATH`
2. Enable `ROUTE_MPATH` in amd64 GENERIC.
3. Turn on `net.route.multipath=1` by default