Deprecate inferred_p use cases

[cmungall]

What does it mean for a class expression to be inferred?

Usually the inferred property would only be applied to an axiom (sentence), not an expression (noun phrase).

So for example, gomodel:987654321 rdf:type <ClassExpression> could be tagged as being inferred.

Perhaps the intent is that the class expression object always represents an assignment for an individual? This introduces a slight impedence mismatch to OWL but could be fine if documented. It may introduce complications, e.g. for a recursive class expression definition. What are the semantics of mixed inferred_p values in a nested CE?

@hdietze to advise

[kltm]

Uhh...this is left to be seen. It being there in the first place is the product of two libraries being merged a few months ago for making the inferred types work the way expected given what we had at the time. It may be that that's no longer necessary (would be handled separately) and can be dropped. We'll find out as I roll the new everything into the graph editor.

[kltm]

Talking to @hdietze a little about this. I believe the reason that it's there is because the way individuals are modelled coming back in from minerva, there is not quite enough information to put it in the right spot: either the inferred information is stored at the (big) individual level (as in the minerva response) or the cls expr level (as in the display); both are wrongish (minerva maintaining two lists of individuals is a bit odd), but I think the cls expr level is definitely more wrong now (although it served its purpose for getting the inferred cls expr information into the display quickly).

I've open geneontology/noctua#30 for the work, and will come back here and close once it's done and I can safely remove the inferred bits.

[kltm]

We are now dealing with these fundamentally differently. This issue is do now remove this code path.