Stop tracking context effects if they are unset

There's a bit of trickiness here. This can cause a subtle bug
if you rely on membership in the context effects dictionary to
determine if an object can be painted. Suppose for example you
had a curve that was highlighted green, and you want to remove
the effect (which consists of changing the colour to black).
Because we are modeling this as removing an effect, the curve
is deleted from the dictionary, and so we skip the curve when
we want to apply the black paint... which results in the curve
seeming to be permanently highlighted
Tidy ConceptDiagramPortlet code up a bit
Tidy up subsumption pattern

Remove copy and paste code from concept pattern
Tighten up SearchHandler interface

Make the subsumption CurveMatchHandler also a SearchHandler
(why not?)
Tidy incorrect comment
Subsumption pattern reset button
Rename Concept to Curve

A concept/class can be represented by one or more curves.
Remove unused imports
Tidy up ConceptDiagramPortlet

Try to regroup scattered bits of code into sensible blocks
Remove stray debug logs for concept selection
Remove stray debug log
Make dialog boxes obscure everything else

Perhaps not a good approach; we give it an arbitrarily
high z-index and hope that other users don't use a higher
one unless they really want to trump the dialog box
Abort curve resize on mouse out.

It's possible to mouse-out unintentionally.
which leads to a confusing interaction where a curve
gets "unexpectedly" resized because yuo weren't expecting to
still have control over it
Remove dead code
Tighten up key equality in effects system

This is partly just avoiding Lombok EqualsAndHashcode unless we really
mean to use it. Nothing particularly wrong with it, mind you, just a
matter of tightening things up.

Also: we want to base our notion of key equality on reference equality
of the objects; because here the intention of the key is to refer to the
object itself, not its contents/state. Without this fix, the effects
tracking system can fail to recognise it's talking about the same key as
the the underlying object is mutated. It's possible that the
Lombok-generated version of equals and hashcode was doing the right
thing here, but I don't understand why it should
Tighten up Lombok usage in conceptdiagram
Multicurve support

Allow a class to be represented by multiple curves on the canvas

We maintain a 1:1 mapping of iri to name (on the assumption that it
would be confusing to have more than one IRI for a given name, although
note that in the future, we may have to model 1:M)

Also rename ConceptManager to CurveRegistry and try to clean up the flow
of control

Cases I can think of:

- rename a curve to a pre-existing name
- renaming the last remaning instance of a curve
- deleting a curve which has a duplicate
- renaming a curve to something new

There may be scenarios I hadn't considered
Remove stray unused class

This was from a time when I was just experimenting with drawing things