OSPFv2 status disappears when OSPFv3 is also running #1700

Current Behavior

With OSPFv2 and OSPFv3 configured at the same time, all OSPFv2 status
is missing from the operational datastore. The CLI reports OSPFv2 as
not running, although ospfd is up and has its configuration.

admin@infix-00-00-00:/> show ip ospf interface
OSPF is not configured or running

Expected Behavior

Both instances are reported. show ip ospf shows the OSPFv2 instance
and show ipv6 ospf shows the OSPFv3 instance.

admin@infix-00-00-00:/> show ip ospf interface
INTERFACE  AREA     TYPE       STATE    COST  PRI  DR  BDR  NBRS
e1         0.0.0.0  Broadcast  Waiting   100    1  -   -       0

Steps To Reproduce

1. Factory reset, or a fresh make run
2. Configure OSPFv2 on an interface with an IPv4 address:
   edit interface e1
   set ipv4 address 192.168.50.1 prefix-length 24
   top
   edit routing control-plane-protocol ospfv2 name default ospf
   set area 0.0.0.0 interface e1 enabled true
   leave
3. show ip ospf interface works
4. Configure OSPFv3 on the same interface:
   edit interface e1
   set ipv6 address 2001:db8:50::1 prefix-length 64
   top
   edit routing control-plane-protocol ospfv3 name default ospf
   set explicit-router-id 1.1.1.1
   set area 0.0.0.0 interface e1 enabled true
   leave
5. show ipv6 ospf interface works, show ip ospf interface now says
   "OSPF is not configured or running"

Additional information

In src/statd/python/yanger/ietf_ospf.py, add_areas() (OSPFv2) and
add_areas6() (OSPFv3) both store their instance with:

insert(control_protocols, "control-plane-protocol", [control_protocol])

insert() in common.py assigns the value, so the second call
replaces the list from the first, and the OSPFv3 entry overwrites the
OSPFv2 one. It was introduced with OSPFv3 support in 1f71075. No
test runs both versions at the same time, so it was not caught.