Feature/kb and labels as annotations

[XanderVertegaal]

This PR builds on #63 and includes the latest version of develop. It develops the original PR's idea of using KnowledgeBaseAnnotations, bound by a AnnotationSession, instead of a KnowledgeBase model that is appended to a Problem directly. I think this is a good change which fits the researcher's vision that user annotations will mainly consist of additions/edits of knowledge base items and proof trees.

AnnotationSessions also have a "notes" field aimed at remarks or justifications. I first implemented that too, but noticed that any notes given when adding a label are overwritten when a label is removed. This would have been easier to implement with the 'Event'/'Change' structure you proposed in an earlier PR review.

[jgonggrijp]

I have read the code with attention, but did not try out the feature.

There is a lot of code and I could not completely oversee the larger structure of it, but most of it looks reasonable to me. I made a relatively large number of comments, but they are all about technical details. I really appreciate the extensive testing of two of the modules.

This PR builds on #63 and includes the latest version of develop. It develops the original PR's idea of using KnowledgeBaseAnnotations, bound by a AnnotationSession, instead of a KnowledgeBase model that is appended to a Problem directly. I think this is a good change which fits the researcher's vision that user annotations will mainly consist of additions/edits of knowledge base items and proof trees.

I suspect this AnnotationSession might end up being a temporary placeholder for what is essentially a proof. This works for now, though.

AnnotationSessions also have a "notes" field aimed at remarks or justifications. I first implemented that too, but noticed that any notes given when adding a label are overwritten when a label is removed. This would have been easier to implement with the 'Event'/'Change' structure you proposed in an earlier PR review.

This reads a bit like an open end for a follow-up branch. What do you want to do in that follow-up? Drop the feature? Have another try at making it work? Switch to an event based data model? In the latter case, I don't think this branch should be merged as is.

[jgonggrijp]

I think I saw tests in manage-labels-modal.component.spec.ts that were mostly testing the behavior of the functions in this module. It would be better to have those tests in a dedicated util.spec.ts, because that makes them easier to find when debugging these functions.