"neutronvpn:createL3VPN" fails to create L3VPN for IPv6 use case.

"neutronvpn:createL3VPN" fails to create L3VPN for IPv6 use case.

a)	Issue: vpnTargets (route-distinguisher/iRT/eRT)
are VPN properties, but according to the VPNInstance
IETF yang model, VpnTargets reside within IP-families
(v4/v6). For Boron based release, only IPv4 family was
supported and thus, making use of ipv4-family ->
vpnTargets sufficed. For R7, this will not work as at
the time of VPNInstance creation, there is no knowledge
of whether v4 or v6 family subnets will be associated
to VPN. Thus, there is no clear model to store vpnTargets.

b)	Manifestation in TRs:  HX53527 - [NFVi] EO request
for "neutronvpn:createL3VPN" fails to create L3VPN:
Pure IPv6 VPNs fail to get VPN connectivity due to
the above anomaly.

c)	Solution: Move vpnTargets and RD out of IP-family
containers. Representation of the new yang-model is as below:
container vpn-instances {
		list vpn-instance {
			list vpnTargets {			}
				Ipv4-family {
				}
				Ipv6-family {
				}
				…
			}
		}
	}

d)	Additional changes:
1.	For use-cases where IPv4 family is being
incorrectly used and functionality is working per chance
need to align with the new model.
2.	Refactoring to remove ipv4-family
and ipv6-family from yang model itself in case
we are not using these at all.

e)	Benefits:
1.	Functional benefits to avoid storing data
inconsistently, and moving towards making our models more logical
2.	Refactoring will lead to cleaner code.
3.	Removing large config containers of ipv4-family
and ipv6 family will lead to performance improvements.

Change-Id: Id33d4931f994f739d31620f8bdc492f15cf8ffd1
Signed-off-by: Surendar Raju <surendar.raju@ericsson.com>