fix Bug#3270: provider bridge residential domain deployment scenario

Descriptions and cause: During the implementation of the provider bridge deployment scenario, it came to light that netifd has an inherent restriction that the 8021ad vlan cannot be setup using the linux naming convention, that is, ethx.y.z

This restriction stems from the initial implementation: https://git.openwrt.org/?p=project/netifd.git;a=commit;h=59217785704fca27d2c7a19e279d27c384a452cd

I can understand that this restriction was introduced becuase netifd has ways on internally generating vlans in case the corresponding device section is not mentioned. So, if ethx.y is the ifname in the interface section and the corresponding device section with name ethx.y does not exist, it would create ethx.y. What is worth noting here is that at this junture, since the device section is not even consulted, netifd has no way of knowing the type of this vlan interface, hence, it assumes it to 8021q and sets up the vlans accordingly.

If this same naming convention is used, then if ethx.y.z is ifname in interface section then ethx.y is created first and then ethx.y.z on top of ethx.y, however, since netifd does not consult the device section, it creates both vlans as 8021q.

Solution: Do not self generate underlying vlan based on the ifname in the interface section, instead always consult the device section. The trade-off then is that we loose the capability of openwrt to self generate underlying vlans.

The second choice ofcourse is that we do nothing in netifd, but instead decide on a seprate naming convention for double tagged interfaces, such as, ethx-y-z