Improve validation of ontologies created outside API v2

[benjamingeer]

The resolution of #286 was that we would focus on validating ontologies created via API v2. But there is also interest in better validation of ontologies created outside the API and loaded when Knora starts: #773. I think it shouldn't be difficult to refactor OntologyResponderV2 somewhat to do the following after loading all ontologies:

• Check that all classes defined in project-specific ontologies are subclasses of knora-base:Resource. (Should it be possible for projects to define other sorts of classes? If so, perhaps there should be a requirement that such classes have non-Knora IRIs.)
• Check that all properties defined in project-specific ontologies are subproperties of knora-base:hasValue or knora-base:hasLinkTo, and are not subproperties of knora-base:hasFileValue. (Same question as above.)
• Check that all cardinalities directly defined on subclasses of knora-base:Resource are for subproperties of knora-base:hasValue or knora-base:hasLinkTo.
• Check that the subproperties of knora-base:hasValue and knora-base:hasLinkTo all have subject classes that are subclasses of knora-base:Resource.
• Check that the subproperties of knora-base:hasValue have object classes that are subclasses of knora-base:Value.
• Check that the subproperties of knora-base:hasLinkTo have object classes that are subclasses of knora-base:Resource.
• Check that the objects of rdfs:subClassOf are subclasses of knora-base:Resource if they have Knora IRIs.
• Check that the objects of rdfs:subPropertyOf are subclasses of knora-base:hasValue or knora-base:hasLinkTo if they have Knora IRIs.
• Check that salsah-gui:guiOrder, salsah-gui:guiElement, and salsah-gui:guiAttribute appear in the correct places.

Other validations that we do when creating ontologies via the API, but might be more work to do in this context:

• Check that the subject and object classes of a subproperty are subclasses of the ones referred to in all its base properties.
• Check that the cardinalities in a subclass are at least as restrictive as the ones it overrides from its base classes.