Explanation Conclusion should include non-retrievable concepts

[jmsfltchr]

What is the goal of this PR?

Introduce a different answer type for conclusions inside explanations. This permits returning any concept, not only retrievable concepts, which is important for returning a thorough explanation due to unification.

What are the changes implemented in this PR?

• Swap ConceptMap for a map

[haikalpribadi]

This message/object is not meaningful given that it wraps one object -- it's a thin wrapper and not canonical. We should keep a simple <map, Concept> message type for conclusion field in Explanation message type.

[haikalpribadi]

I've revered this PR in a subsequent commit. Reason is the same as what I posted on Client Java's PR:

We've concluded that this change, along with the Protocol prerequisite change, does not arrive at meaningful data structure. Replacing ConceptMap with Map<Str,Concept> was not meaningful given that we still provide users with the same information but with different APIs. The only change is that the users are now restricted from calling .explanations() but that wasn't bad to begin with, given that the return was empty. Using ConceptMap, albeit providing richer API (with .explanations()) than necessary was not bad given that it's still consistent. We think the there's more to this discussion, in that we need to: a) look at the overall design of ConceptMap with with a fresh perspective, and b) review more of what reasoner's new data structure actually needs. Both will need to happen in the future, and thus for now, we should stick with the current API we have.