properly handle existing routes on VRF attachement/detechment

[KanjiMonster]

When attaching a VRF to or from a VLAN interface, we remove the ip addresses since we will get new address notifications for the correct new table (VRF). But routes may also already exist, and may stay in the original table. Especially on detachment, we fail to remove the routes again, so VRF assigned routes can remain.

Additionally, the IPv6 LL route check didn't consider the table, so it would fail to remove the VRF IPv6 LL route if there were other non-VRF LL routes. So make sure to match on the table as well.

Motivation and Context

Fixes #290

How Has This Been Tested?

Ran weekend pipelines with PR applied, no observed regressions.

To verify ran the vrf-lacp test on as4610.

After running the test:

accton-as4610-54:~$ client_flowtable_dump  30
Table ID 30 (Unicast Routing):   Retrieving all entries. Max entries = 32768, Current entries = 5.
--  etherType = 0x0800 vrf:mask = 0x000a:0xffff dstIp4 = 10.0.1.0/255.255.255.0 dstIp6 = ::/:: | GoTo = 60 (ACL Policy) outPort = CONTROLLER (Reserved)  | priority = 2 hard_time = 0 idle_time = 0 cookie = 33
--  etherType = 0x0800 vrf:mask = 0x000a:0xffff dstIp4 = 10.0.2.0/255.255.255.0 dstIp6 = ::/:: | GoTo = 60 (ACL Policy) outPort = CONTROLLER (Reserved)  | priority = 2 hard_time = 0 idle_time = 0 cookie = 36
--  etherType = 0x0800 vrf:mask = 0x000a:0xffff dstIp4 = 10.0.3.0/255.255.255.0 dstIp6 = ::/:: | GoTo = 60 (ACL Policy) outPort = CONTROLLER (Reserved)  | priority = 2 hard_time = 0 idle_time = 0 cookie = 35
--  etherType = 0x86dd vrf:mask = 0x0000:0x0000 dstIp4 = 0.0.0.0/0.0.0.0 dstIp6 = fe80::/ffff:ffff:ffff:ffff:: | GoTo = 60 (ACL Policy) outPort = CONTROLLER (Reserved)  | priority = 2 hard_time = 0 idle_time = 0 cookie = 23
--  etherType = 0x86dd vrf:mask = 0x000a:0xffff dstIp4 = 0.0.0.0/0.0.0.0 dstIp6 = fe80::/ffff:ffff:ffff:ffff:: | GoTo = 60 (ACL Policy) outPort = CONTROLLER (Reserved)  | priority = 2 hard_time = 0 idle_time = 0 cookie = 28

accton-as4610-54:~$ sudo ip l d red
accton-as4610-54:~$ client_flowtable_dump  30
Table ID 30 (Unicast Routing):   Retrieving all entries. Max entries = 32768, Current entries = 3.
--  etherType = 0x0800 vrf:mask = 0x0000:0x0000 dstIp4 = 10.0.1.0/255.255.255.0 dstIp6 = ::/:: | GoTo = 60 (ACL Policy) outPort = CONTROLLER (Reserved)  | priority = 2 hard_time = 0 idle_time = 0 cookie = 63
--  etherType = 0x0800 vrf:mask = 0x0000:0x0000 dstIp4 = 10.0.3.0/255.255.255.0 dstIp6 = ::/:: | GoTo = 60 (ACL Policy) outPort = CONTROLLER (Reserved)  | priority = 2 hard_time = 0 idle_time = 0 cookie = 65
--  etherType = 0x86dd vrf:mask = 0x0000:0x0000 dstIp4 = 0.0.0.0/0.0.0.0 dstIp6 = fe80::/ffff:ffff:ffff:ffff:: | GoTo = 60 (ACL Policy) outPort = CONTROLLER (Reserved)  | priority = 2 hard_time = 0 idle_time = 0 cookie = 61

accton-as4610-54:~$ ip r
default via 172.16.111.1 dev enp0 proto dhcp src 172.16.111.111 metric 10 
10.0.1.0/24 dev swbridge.10 proto kernel scope link src 10.0.1.1 
10.0.3.0/24 dev swbridge.30 proto kernel scope link src 10.0.3.1 
172.16.111.0/24 dev enp0 proto kernel scope link src 172.16.111.111 metric 10 
172.16.111.1 dev enp0 proto dhcp scope link src 172.16.111.111 metric 10 
172.16.111.2 dev enp0 proto dhcp scope link src 172.16.111.111 metric 10 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 

(VRF targeting) routes are now gone after deletion, and match the actual route table.

[KanjiMonster]

Images with the changes included:

http://repo.bisdn.de.s3-eu-central-1.amazonaws.com/nightly_builds/generic-armel-iproc/main/onie-bisdn-full-generic-armel-iproc-202505231632.bin
http://repo.bisdn.de.s3-eu-central-1.amazonaws.com/nightly_builds/generic-x86-64/main/onie-bisdn-full-generic-x86-64-202505231651.bin