[PATCH] filter: Add bgp_next_hop_global and bgp_next_hop_ll for independent IPv6 next hop access

[KSKB SHI]

Thank you for the review.
I looked into implementing the method-based approach (bgp_next_hop.set_global() / bgp_next_hop.set_local())
but the current lvalue.method pipeline goes through GET (adata → T_IP,  #### nh[1] lost here #### ) → method → SET (T_IP → adata)

The method approach doesn't cleanly, because the method operates on T_IP (a single address) but the underlying storage is an adata with 2 addresses.
It will lost the second value once we GET the variable.

Making it work would require either a new type to carry both addresses through the pipeline, or custom instructions that bypass the method infrastructure entirely
both more invasive than the da.bit approach.

>From my analysis, the da.bit approach is the minimal change. The method-based approach would require more code and be more invasive, while still being a hack, just in a different place.

I agree that the type system rework is the best solution for 3.x. But for the 2.x branch, where the type system rework won't land, the da.bit approach could be worth considering as a non-invasive stopgap, it touches only two files, preserves full backward compatibility, and can be cleanly dropped once 3.x type system rework is available.

Best regards
KusakabeShi