Decouple Anchor from Fragment proposal

Problem description

The initial decision regarding DB schema is described in CCSDK-2756 DM: [Spike] Propose C&PS Data Model#2.2Genericschema(currentproposal) 

It was decided to store anchor and data fragments in a same table (FRAGMENT). 

The only reason mentioned is possible root level leaf definitions which may require the attributes (data) to be stored within
an anchor record itself. So these attributes could be requested from anchor node which serves a role of a root data node.

However using the ODL yangtools library for data parsing shows the initial assumptions (the decision was based on) were inaccurate:

• Anchor is referencing single module  → false, anchor references schema set (may contain multiple modules)
• Module represents the model root, module root elements describing child nodes → false, each root element of the model
  describes own model (as treated by yangtools), each root level leaf will be treated as standalone data node

NB. the issue with unexpected data root is mentioned in ModuleSet cases analysis#Issuedescription

This makes Anchor record persistence within a Fragment table useless, because it will never be treated as root data fragment
(as it was initially expected) and it should not.

Anchor and data fragments are different data types, which are managed differently. Even the sets of fields are not intersected.
So there there is no any benefit storing anchors and data fragments at the same table. In opposite there is an extra complexity 
managing both anchors and data fragments + performance impact.

Proposal

While nothing justifies initial decision it seems reasonable to split anchor and data fragment storage to two separate tables.

Pros: 

• Logical data separation, no confusion, no necessity for explicit description why configuration and data are stored at same table
• Performance improvement, due to number of anchor records (expected) is significantly lower then the amount of data fragments
• No extra complexity in data processing (CRUD implementation) and dependency management (FK constraints)

Cons: 

• Some refactoring work
  Mitigation: make decision soon and act on up to prevent it becoming more difficult

Cases

module test1 {
    yang-version 1.1;
 
    namespace "org:onap:cps:test1";
    revision "2020-01-01";
    prefix "base";
 
	    leaf name {
            type string;
        }
        leaf description {
            type string;
        }
}

module test2 {
    yang-version 1.1;
 
    namespace "org:onap:cps:test2";
    revision "2020-01-01";
    prefix "base";
 
	    leaf name {
            type string;
        }
        leaf description {
            type string;
        }
}