add a method to cps-service/src/main/java/org/onap/cps/api/CpsModuleService.java to retrieve all modules and version known by CPS

Open Question

1. RestConf module information contain both Name and Namespace (as well as revision). Do we need both of these for uniqueness?  https://datatracker.ietf.org/doc/html/rfc6020#section-5.1 states "The names of all standard modules and submodules MUST be unique". The pitfall could be the word 'standard' here and it might be good to include dataspace as  well. https://datatracker.ietf.org/doc/html/rfc6020#section-5.3 states that "Namespaces for private modules are assigned by the organization owning the module without a central registry. Namespace URIs MUST be chosen so they cannot collide with standard or other enterprise namespaces, for example by using the enterprise or organization name in the namespace." 

Notes

1. 'internal java API' only not to be exposed on REST
2. prevent duplicated data but ensure data is convenient for checking against list of modules (names and revisions and ?) as retrieved using RESTConf (current DB schema does not seem to align with this?!
3. currently cps does NOT store module meta data (name, revision, namespace)

Steps

1. Propose changes to https://wiki.onap.org/display/DW/CPS+Internal+Relation+DB+Schema to add fields for module metadata in yang-resource table (agree with team)
   Note. schema is now a screenshot from other tool. Probably best to replace with build-in confluence diagram tool.
2. Add Liquibase steps to update schema (incl. rollback ?!)
3. Update org/onap/cps/spi/entities/YangResourceEntity.java with new fields
4. PROBLEM!!! org.onap.cps.yang.YangTextSchemaSourceSetBuilder#generateSchemaContext uses identifiers based on the 'filename' instead of module.-name and revision. Once the SchemaContext is build there is no way to link back to the source it was build from.

 Out-of-scope

1. Update of existing data (pre-populated modules) is not needed