Align implementation with specification

[kshychko]

A new schema was developed according to the specification - https://github.com/kshychko/edi3-model-interchange/blob/develop/docs/domain-schema.json
It is in my fork and can be updated, but please start with it.

I developed a sample project trying to make it simple, but covering the rules needs to be applied to convert export a project in StarUML format to interchange format. The samples cover the Domain Model Interchange Specification only. For the other two specifications separate issue will be raised.
domain-sample.zip

Some comments:

1. If @onthebreeze approves, I want to rename "packages" to "contexts". This concept is missing from the current specification, but that's something we need to add to it as I think.
2. I introduced "DataTypes" array and it is in the root of the project as to my understanding data types are share across contexts. I think we need a rule that a DataType can be defined in a root of the project, in a domain package, or in a context package. But let's get back to this later.
3. Pay attention that if a property is empty it doesn't need to be included.
4. If a relationship's target entity belongs to the same context, the context doesn't need to be specified.
5. When you parse a relationship it doesn't matter where it is located in the project. What matters is that the end with aggregation !=none is a source entity, not a target one. When aggregation == none for both ends, the target is end1, even that relationship object is the owned element of the class specified in end1. It's confusing but that is how StarUML allows you to draw relations - from child to parent, but we need to define relationships in parent entities.
6. Entity/Property/Relationship may have a status. I added an enumeration and used tags "status" with reference type to cover it. Hope the sample makes it clear.

@faizanvahevaria , please feel free to ask any questions, if anything is unclear or you are not sure how to implement the changes. I likely missed something, but I'll update the ticket.

[faizanvahevaria]

@kshychko
Questions.

1. StarUML allows user to add more than one tags(StatusCode), what should the extension do if it encounters more than 1 tags in a attribute/property?

2. Should we allow the user to select any one package/context while exporting to Model Interchange format? or just export the entire project directly? By looking at your sample.json file, it seems like the file is a complete project.

3. Will all the StarUML files have a package named "DataTypes" ? or the name might be different?

4. Will all the StarUML files have an enum "StatusCode" ? or the name might be different?